The vendor is required to provide to convert water rights and water use data currently in microsoft FoxPro (all free tables, not wrapped in a database container) to an ESRI, GIS-centric database solution with an annual water use reporting requirement, including retention of historical water reporting use.
1. Status of existing microsoft visual FoxPro data
- Water rights database. five tables currently in a one-to-one relationship as free tables, not within a database container:
• Prmtinfo.dbf
• Admninfo.dbf
• Irrginfo.dbf
• Wellinfo.dbf
• Daminfo.dbf
- Irrigation water use reporting database. one table, not within a database container:
• Iquest.dbf
- Status of existing of microsoft access data
- Nonirrigation water use reporting data.
• H20use.mdb
3. Data conversion overview
• The goal is to migrate our existing water rights data into a modern ESRI, GIS-centric database application with basic functionality which will be described in the following sections.
• It is anticipated there will be an ongoing service agreement for professional services concerning maintenance, possibly hosting, and feature additions as funds allow.
• The successful offeror needs to specify in their quote the price for the completed application to be hosted by the offeror compared with the price for the completed application being hosted by the state
• This price comparison needs to identify pros and cons of both solutions and security provisions either required by state or employed by the offeror, or both, if the solution is hosted by the offeror.
4. Data conversion
- Water rights database.
• Data needs to be extracted from the FoxPro tables which the state can provide to the contractor in a generic DBF or XLS format.
• Converted data will need to be modified by the contractor as needed to create the new ESRI GIS-centric database application including numerous one-to-many relationships that do not currently exist. records in the database exist into perpetuity and each record has a pdf associated with it that needs to be accessible from the interface.
• Pdfs will not be stored within the new database container but will be accessed via a storage location mutually agreed upon by the offeror and the state
• The new ESRI GIS-centric database application needs the following features with single sign on integration with role-based security to limit editing capabilities to agency staff:
• A user interface so agency staff can enter records into the database and modify existing database entries as needed.
• The user interface needs to accommodate entry not only of tabular data, but gis-centric data such as points and polygons.
• The user interface needs to accommodate robust search capabilities, using both tabular content and GIS-based content
• The solution will require use of captcha.
• The capability to output search results into formats, such as xlsx, which can be used for MS word mail merges or used in adhoc reports allowing summarizing/grouping of search results.
• Direct access to the data from within ArcGIS pro will be needed to accommodate doing customized searches that may not be available within the user interface.
• Currently, the state is using ArcPro server version 11.3 and ArcPro 3.3.
• Certain records (permits – parent) in the database reserve an amount of water for future use and are subject to review every seven years.
• Other records (permits) take a specified amount of water out of the reserved water from what could be considered the “parent” permit.
- Irrigation water use reporting database.
• Data needs to be extracted from the FoxPro tables which the state can provide to the contractor in a generic DBF or XLS format.
• Records in this dataset contain annual reported water usage for records housed in the water rights database described above.
• There is no GIS-related data in this dataset, GIS-related information is housed with the water rights database with the permit number field serving as the key field to relate the datasets
• Caspio does support “web hooks” allowing a data connection between Caspio and another dataset.
• pdfs will not be stored within the new database container but will be accessed via a storage location mutually agreed upon by the offeror and the state
• The new database application needs the following features with single sign on integration with role-based security to limit editing capabilities to agency staff:
• A user interface so agency staff can enter records into the database and modify existing database entries as needed.
• This includes the ability to enter historical data not currently in digital format
• A few additional fields may be needed such as a contact person/renter name, address, etc. for reporting annual water use
• This database interface needs a connection to the user interface developed for the water rights database so edits can also be made in the water rights database.
• The user interface needs to accommodate robust search capabilities, using both tabular content and GIS-based content available in the water rights database
• Beginning-of-the-reporting year
• Mid-year
o A second cover letter and notice (one of three versions) needs to be generated, saved as a pdf, and mailed to permit holders who have failed to report water use.
o An export of the cover letter data as an xlsx file for a MS word merge is an acceptable option.
o Blank reporting forms will also need to be generated to this mailing
• End-of-the-reporting year.
o Pdf generation for each record showing the reported water use data is needed as part of this project with each pdf named by permit number and year of reporting, e.g., 5432-3_2024.pdf
o Three summary reports of all reported data need to be generated with the ability to save the generated reports as pdf documents for archival purposes.
o Archival of the data which will be accessible from within the developed application.
5. Non-functional requirements
a. Solution access and supported browsers
• The solution must only require internet browser software for users to access it.
• All state of web sites and software will be developed using technology that is compatible with all popular, modern web browsers.
• No site or application will be created using proprietary features available to the visitor only when using a Certain brand of web browser.
b. Single sign-on requirements
• The state’s identity and access management (IAM) strategy, the proposed solution will need to integrate with the state of standard identity management service single sign-on (SSO) which enables custom control of how citizens and state employees sign up, sign in, and manage their profiles
• The SSO supports the industry standard OAuth 2.0 protocol.
• This identity management will handle password recovery and multi-factor authentication (MFA).
• MFA is required for all application administrators and may be required for other users
c. SSO logout initiation
• Users must be able to initiate a logout from any SSO-protected application.
• A clear and easily accessible logout mechanism (e.g., a "logout" button/link) must be provided within each application's user interface.
• Initiating a logout from any SSO-protected application must trigger a session-based logout process utilizing the sign-out endpoint found in the metadata document provided during implementation.
d. Session timeout
• Inactive user sessions must automatically time out after a state-defined period.
• This timeout period may be adjusted for specific applications based on risk assessment and business requirements, with approval from bit.
• Users must be notified of impending session expiration 5 minutes before the timeout occurs, providing them with the option to extend their session.
e. Session termination on browser close
• Closing the browser window or tab must not be considered a valid logout. while the browser session might end, the SSO session may remain active.
• Users are responsible for explicitly logging out to ensure complete session termination.
• Clear communication regarding this behavior should be provided to users.
f. Onboarding and provisioning users
• The offeror shall provide an automated process for onboarding and offboarding users in the system using an external identity provider.
• If an automated process is not available, the vendor shall detail the process for onboarding and offboarding users that requires minimal manual steps.
• Vendor shall provide an identity/SSO/login design document which illustrates all interactions between the system, its components and an external identity provider.
g. Solution diagram
• The offeror must provide a solution diagram providing specific details of how the entire solution will meet the requirements
• This will include integration with the state’s infrastructure, existing systems that will integrate with the proposed solution, how data would flow between systems, the technology stack of the solution including any dependencies, and include, but not be limited to, user onboarding/provision and SSO.
• All components, tools and products that the solution utilizes to meet the requirements should be depicted.
h. Accessibility requirements
• Websites that are not open to the public must be secured by user login, which can be managed based on role configurations.
• Websites should be Americans with disabilities act (ADA) compliant.
- Contract Period/Term: 2 years
- Questions/Inquires Deadline: April 14, 2025