PVD_Ratio_Study_Project_Requirements.xlsx
XLSX spreadsheet 26 KB Posted
- Attached to
- Tax Appraisal Ratio Study Software System
- Solicitation number
- EVT0009555
- Issued by
- Shawnee County, Topeka City, Kansas
About this file
The document is a Request for Proposal (RFP) from the Property Valuation Division (PVD) of the Kansas Department of Revenue (KDOR) seeking a contractor to provide a Property Tax Appraisal Ratio Study Software solution. The new program would replicate and improve the existing Visual Basic 6 (VB6)-based system and Excel macro-driven functionalities that format and compile preliminary data to upload/integrate into a single ratio study program. The RFP outlines detailed functional and technical requirements, including the ability to import and process appraisal and sales data for all 105 counties in Kansas, generate various ratio study reports, identify outliers, and maintain similar processing times as the current system. The proposed contract is for one (1) year with the option for four (4) one-year renewals.
The RFP specifies that the software must be developed in Python or another modern and maintainable programming language and can be provided as either a desktop or web application. The RFP also emphasizes the importance of the vendor's ratio study experience and ability to meet the requested timeline. Pricing terms, set-asides, and funding requirements are not explicitly detailed in the RFP, but the successful vendor will be expected to address these in their cost proposal.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Cost_Sheet.pdf | ||
| Tax_Appraisal_Ratio_Study_Software_System.pdf | ||
| Sample_Report_Prelim-005.xls | XLS spreadsheet | |
| Amendment_1_-_Q_A_Bid_Extension.pdf | ||
| Sample_Report_Final-003.xlsx | XLSX spreadsheet | |
| Sample_Report_Prelim-006.pdf | ||
| Sample_Report_Mid-Year-001.pdf | ||
| Sample_Report_Final-001.pdf | ||
| RFP_Tax_Ratio_Study_System.pdf | ||
| Sample_Report_Prelim-002.xls | XLS spreadsheet | |
| Sample_Report_Prelim-004.xlsx | XLSX spreadsheet | |
| Sample_Report_Prelim-003.pdf | ||
| Sample_Report_Prelim-001.xlsx | XLSX spreadsheet | |
| Sample_Report_Final-002.xlsx | XLSX spreadsheet | |
| Input_and_Output_Examples.pdf |
Show all 15
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
Instructions
| Requirements Tab Contents | |
| Instructions | |
| Response Fields for Proposer | |
| Response Code Definitions | |
| Requirements Abbreviation Definitions | |
| Functional and Technical Requirements Matrix Instructions | |
| Proposers must indicate whether their proposed software offering meets the listed requirements by providing a response to each individual requirement using the legend that follows. | |
| Response Fields for Proposer | |
| The Requirements charts on the following Tabs detail the functional and technical requirements of the system. | |
| Offerors must fill in the 3 columns for each requirement in the Requirements section: | |
| 1. Degree of Fit Response (see codes below) | |
| 2. Comments Supporting Response (brief explanation of proposed capability) | |
| 3. Document Reference (In addition to the Comments Supporting Response. | |
| Offeror may make reference to other submitted documents for further explanation/clarification, including document name, pages, paragraph numbers. | |
| Response Code Definitions | |
| SF | Standard Functionality: The software provides the requested functionality without screen, code, or design changes. The product can satisfy the specification “out-of-the-box” without any modification to the standard baseline software offering. Only use “SF” if the baseline software as delivered in the current release fully meets the requirement “as is” or through software configuration. |
| NR | Provided in Next Release: The next release of the software will provide the requested functionality without screen, code, or design changes. Only use “NR” if the very next release of the baseline software will fully meet the requirement. Only formal releases that have been published and are accessible on the software vendor's web site shall be considered when addressing this requirement. A brief identifier/description of the referenced release shall be included in the “Comments” section. |
| MI | Minor Modification: Minor modifications must be made to the standard software offering utilizing the delivered “Development Toolset” to satisfy the specified requirement. Examples of minor modifications include changing a field length and creating a new view. In no case, however, can a modification exceeding 80 hours of estimated work effort be considered minor, regardless of the development method. A brief explanation is required to support any proposed minor modification. Explanations shall be provided in the “Comments” section of the matrix. Estimated costs and work effort associated with each minor modification will be addressed in the separate cost proposal. |
| MA | Major Modification to Source Code Required: Modifications meeting either of the conditions listed below must be made to the standard software offering to satisfy the specified requirement: |
(1) Estimated work effort for design, coding, and unit testing exceeds 80 hours; or
(2) Change to underlying source code.
A brief explanation is required to support any proposed major modification. Explanations shall be provided in the “Comments” section of the matrix. Estimated costs and work effort associated with each major modification will be addressed in the separate cost proposal.
| RQ | Provided through Custom Reporting or Query Tool: The software and datawarehouse supports the data elements necessary for the report/query, but a custom report/query would need to be developed to meet the requirement. A brief explanation is required to support any proposed custom report/query. Explanations shall be provided in the “Comments” section of the matrix. Estimated costs and work effort associated with each custom report/query will be addressed in the separate cost proposal. |
| CD | Custom Development: The desired feature or functionality is not available as part of the standard (baseline) software functionality but can be custom-built to satisfy the specified system requirement. A brief explanation is required to support any proposed custom development; explanations shall be provided in the “Comments” section of the matrix. Estimated costs and work effort associated with each custom development effort will be addressed in the separate cost proposal. |
| TP | Third Party Software/Hardware Required: The desired feature or functionality is not available as part of the standard (baseline) functionality, but is a standard feature of third-party software/hardware proposed to satisfy the specified system requirement. The third-party software/hardware, which is fully integrated with the proposed primary solution, provides the requested functionality without screen, code, or design changes. The proposed third party product can satisfy the specification “out-of-the-box” without any modification to the standard baseline offering. Only use “TP” if the third party product fully meets the requirement. All costs associated with third party product must be addressed in the separate cost proposal. |
| NA | Cannot Meet Requirement: The desired feature or functionality is not available as part of the standard (baseline) software functionality, in the next software release, through modification/enhancement, reporting tools, or third party software. The requirement would most likely need to be met by a process workaround or by interfacing to an existing legacy application. |
| Requirements Abbreviation Definition | |
| GEN | General Requirements |
| LIC | Licensing Requirements |
| ENF | Enforcement Requirements |
| EAA | Enforcement Agent Assignment Requirements |
| EVD | Evidence Requirements |
| REP | Reports Requirements |
| REV | Revenue Accounting Requirements |
| BRG | Brand Registrations Requirements |
| CMB | Cereal Malt Beverage Requirements |
| ADM | Administrative Requirements |
| PUB | Public Requirements |
| TECH | Technical Requirements |
&"-,Bold"Alcoholic Beverage Control Project Instructions
General Requirements REQ # Mandatory Preferred Requirements Fit Rating Comments (Brief explanation of proposed capability) Document Reference
| Y | Functionality and experience doing Ratio Studies and Statistical calculations | |
| Y | Application can be downloaded, installed and run by users on local desktops. | |
| Y | Ability to import and process appraisal and sales data for all 105 counties in Kansas in CSV format (currently supported by KDOR) or alternate MS Excel format if applicable. | |
| Y | Rewrite code/functionality (preferably Python) in the KDOR native RatioEx2015 desktop app to generate current recognized Ratio Calculations | |
| Y | The rewrite will include appraisal median ratio, COD Coefficient of Dispersion (COD), Price Related Differential (PRD) and confidence intervals at various levels for various metrics for each property class using the advanced statistical methods currently utilized by PVD, including: |
- Bootstrapping: which allows estimation of properties like standard errors and confidence intervals for statistics like the median without requiring assumptions about the shape of the population distribution. The resampled datasets mimic the process of drawing many samples from the real populations and is essential for our ratio study creation process.
- Jackknifing: which resamples by leaving out observations rather than sampling with replacement, but allows similar estimation of standard errors, confidence intervals, and bias correction on statistics like the median ratio.
| Y | Create Individual County and Statewide Statistics Report |
| Y | Create Mid-year Ratio Study Report |
| Y | Create Preliminary Ratio Report and Publication Report |
| Y | Create Final Ratio Report and Publication Report |
| Y | Create Substantial Compliance statewide summary report |
| Y | Create Substantial Compliance Scorecard document and Procedural Compliance mass PDF document creation |
| Y | Residential Sampling Program - Replicate the current VB6 sampling methodology used in the current sampling program to a modern programming language (preferably Python). |
| Y | Automatically identify outliers on a per-parcel basis (Criteria will be provided). |
| Y | Create Outlier Sale Report County Substantial (Statistical & Procedural) Compliance Scorecard reports |
| Y | Provide trend reporting capabilities within the ratio program. |
| Y | Maintain similar processing times as current functionality; for example, processing 105 counties currently takes less than 30 minutes. |
| Y | Generate statistical outputs for all property types, including but not limited to, residential, commercial, agricultural, vacant land. |
| Y | Validate the outputs replicate those created by the existing VB6 system using sample data provided by PVD/KDOR. |
| Y | Program software preferred to be developed in Python or other modern and maintainable programming language. |
| Y | Create software as a desktop application (Preferred) or as a web application. |
&"-,Bold"&K000000ABC Project General Requirements
Pro-Cons
| Criteria | Pro | Con |
| Response format as required by the RFP | ||
| Adequacy and completeness of proposal | ||
| Vendor's understanding of the project | ||
| Compliance with the specifications, terms, and conditions of the RFP | ||
| Ratio Study Experience | ||
| Ability to meet requested timeline | ||
| Proposed cost | ||
| On going support options |
File details come from the government source that posted it. Updated .