RFP_2200_GTG3007_ATT_7_v2.xlsx
XLSX spreadsheet 100 KB Posted
- Attached to
- Enterprise Asset Management (EAM) Solutions
- Solicitation number
- RFP 2200 GTG3007
- Issued by
- Texas
About this file
This is a Technical Requirements Matrix (Appendix D) for the City of Austin's Enterprise Asset Management (EAM) and Computerized Maintenance Management System (CMMS) procurement. The document establishes 125 mandatory functional requirements organized across six categories: Reporting (9 requirements), Mobile (25 requirements), Portal (30 requirements), GIS (29 requirements), General Technology (22 requirements), and Systems-Interfaces (10 requirements). Requirements are designated as High (111) or Low (14) priority. Vendors must indicate whether each requirement is met through Configuration (C), Business Rule Automation (A), both (B), or none (N), and if not met through standard functionality, whether customization, future product release, or third-party integration will satisfy the requirement. The matrix requires vendors to provide detailed explanations for each response, and blank responses are interpreted as "No." The RFP includes a mandatory data migration scope matrix requiring vendors to describe their approach to planning, executing, validating, and supporting migration of legacy system data including asset master data, work order history, preventive maintenance records, inspections, inventory, labor data, documents, and user roles into the proposed solution.
The Technical Requirements Matrix serves as the primary evaluation tool for assessing vendor proposals against the City's functional needs for a modern, scalable, cloud-based system supporting 500+ concurrent users with 99.9% uptime SLA. Key functional areas include mobile field operations with offline capability, GIS integration with ESRI Utility Network compatibility, three independent web portals (Staff, Contractor, and Facilities) with configurable access levels, and comprehensive reporting and analytics capabilities. The system must integrate with multiple external platforms including GraniteNet (infrastructure inspection), Maximo (asset management), Microsoft Active Directory (authentication), AclaraOne (advanced metering infrastructure), AMANDA (permitting), Salesforce (customer service), Motorola CSR 311 (citizen reporting), CC&B (billing), and ESRI GIS systems. Compliance requirements include WCAG 2.1 accessibility standards, NIST security standards, TLS 1.3+ encryption in transit, AES-256 encryption at rest, role-based access control, multi-factor authentication, and adherence to Austin City Code 2-11-11 and Texas Local Government Records Act for data retention and disposition. The system must support real-time or near real-time data synchronization with GIS systems and the data warehouse while maintaining audit logging of all synchronization activities and supporting deployment of approved configurations from lower to higher environments without duplication.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| RFP_2200_GTG3007_ATT_6_v1.xlsx | XLSX spreadsheet | |
| RFP_2200_GTG3007_ATT_2_v2.xlsx | XLSX spreadsheet | |
| RFP_2200_GTG3007_ATT_2_v1.xlsx | XLSX spreadsheet | |
| RFP_2200_GTG3007_ATT_9_v1.xlsx | XLSX spreadsheet | |
| RFP_2200_GTG3007_ATT_6_v3.xlsx | XLSX spreadsheet | |
| RFP_2200_GTG3007_ATT_4_v1.pdf | ||
| RFP_2200_GTG3007_ATT_7_v1.xlsx | XLSX spreadsheet | |
| RFP_2200_GTG3007_ATT_14_v1.pdf | ||
| RFP_2200_GTG3007_ATT_15_v1.pdf | ||
| IFB_6100_CLMC971_PLANS_1_v1.pdf | ||
| RFP_2200_GTG3007_ATT_3_v1.docx | DOCX document | |
| RFP_2200_GTG3007_ATT_13_v1.pdf | ||
| RFP_2200_GTG3007_ATT_5_v1.pdf | ||
| RFP_2200_GTG3007_ATT_10_v1.docx | DOCX document | |
| RFP_2200_GTG3007_ATT_16_v1.pdf | ||
| RFP_2200_GTG3007_ATT_17_v1.pdf | ||
| RFP_2200_GTG3007_ATT_1_v1.pdf | ||
| RFP_2200_GTG3007_ATT_1_v9.pdf | ||
| RFP_2200_GTG3007_ATT_11_v1.pdf | ||
| RFP_2200_GTG3007_ATT_12_v1.pdf | ||
| IFB_6100_CLMC971_PLANS_2_v1.pdf | ||
| RFP_2200_GTG3007_ATT_8_v1.xlsx | XLSX spreadsheet |
Show all 22
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
| Appendix D - Technical Requirements V1 |
| City of Austin |
Vendor Instructions
Instructions Offeror shall complete and submit this Technical Requirements Matrix with their proposal response.
For each requirement, Offeror shall complete the following columns:
1. Meets Requirement (Y/N) - Use this column to indicate whether the proposed solution satisfies the stated functional requirement.
2. Product Configuration, Business Rule Automation, Both, or None (C, A, B, N) - Use this column to indicate how the proposed solution satisfies the requirement:
C = The requirement is satisfied through the application's standard, native functionality and may require only standard application configuration using low-code or no-code administrative tools. This includes features that are available out of the box as well as those requiring only routine configuration by a trained application analyst or system administrator A = The requirement is satisfied using the application's native business rule or workflow automation capabilities without requiring custom programming.
B = The requirement is satisfied through a combination of both Configuration and Business Rule Automation.
N = The requirement is not satisfied through Configuration or Business Rule Automation. If N is selected, indicate whether the requirement is met through Customization, a Future Product Release, or Integration with a 3rd Party Product, as applicable.
3. Customization (Y/N) - Use this column to indicate that the requirement is satisfied through custom-developed functionality or scripting requiring software development knowledge. Examples include SQL, Python, Java, JavaScript, VB Script, C#, APIs, plugins, or other custom-developed components beyond standard application configuration. Provide additional details under the Explanation/Comments column.
4. Future Release (Y/N) - Use this column to indicate that the requirement will be satisfied in a future product release. Provide the anticipated product version and expected release date, if available, under the Explanation/Comments column.
5. Integration / 3rd Party Product (Y/N) - Use this column to indicate that the requirement is satisfied through integration with a third-party application, product, or service. Identify the proposed third-party product under the Explanation/Comments column.
6. Explanation / Comments - Use this column to provide any additional information necessary to explain the proposed solution, including configuration approach, customization details, future release information, third-party products, assumptions, limitations, or any other information that will assist Austin Water in evaluating the response.
7. Blanks in any column will be interpreted as No
For Section F, Systems – Interfaces, Offerors shall complete only the vendor response columns for each external system listed in the table.
Indicate Yes/No (Y/N) for Vendor Experience, Standard Connector, Custom Integration Required, and Preferred Integration Partner.
Provide additional details, as needed, in the Explanation/Comments column.
Notes Offeror must address all requirements included in this Requirements Matrix, including those designated as High (H), Medium (M), and Low (L).
A response of Yes (Y) in the Meets Requirement column does not require the requirement to be satisfied solely through Configuration or Business Rule Automation. A requirement may also be satisfied through Customization, a Future Product Release, or Integration with a 3rd Party Product, as indicated in the applicable columns.
If Meets Requirement = No (N), the Offeror should explain why the requirement cannot be met in the Explanation/Comments column.
&G &"-,Bold"&18Instructions City of Austin
Table of Contents
| City of Austin |
| Technical Requirements |
Table of Contents
| Category (Tab) | # of Requirements | ||
| High | Low | Total | |
| A. Reporting | 7 | 2 | 9 |
| B. Mobile | 21 | 4 | 25 |
| C. Portal | 24 | 6 | 30 |
| D. GIS | 27 | 2 | 29 |
| E. General Technology | 22 | 0 | 22 |
| F. Systems - Interfaces | 10 | 0 | 10 |
Totals 111 14 125
&G &"-,Bold"&18Table of Contents City of Austin
Page &P
A. Reporting
| System Functionality Category | ID | Type | Requirement | Priority (H, M, L) | Meets Requirement (Y/N) | (C)onfiguration, (A)Business Rule Automation, (B)oth, or (N)one | Customization (Y/N) | Future Product Release (Y/N) | Integration /w 3rd Party Product (Y/N) | Explanation/Comments |
| Reporting | 1 | Reports | The system shall support configurable dashboards that may be used to display analytics (including assigned tasks, geospatial data, Key Performance Indicators, etc.) for different users or user groups | H | ||||||
| Reporting | 2 | Reports | The system shall provide built-in ad-hoc reporting capabilities on all data elements. | H | ||||||
| Reporting | 3 | Reports | The system shall provide the ability to create pre-defined reports on all data elements. | H | ||||||
| Reporting | 4 | Reports | The system shall allow user to drill into detailed report data by clicking on a work record or asset ID. | H | ||||||
| Reporting | 5 | Reports | The system shall support scheduled reports that are sent to specific users or user groups. Reports to support multiple formats including but not limited to PDF, Excel, Word, CSV, XML, PBIX etc. | H | ||||||
| Reporting | 7 | Reports | The system shall provide workflow-based metrics to be used to track Key Performance Indicators (e.g., # of WO completion, etc.). | H | ||||||
| Reporting | 8 | Reports | The system shall provide canned reports such as error and exception reports, access violations, usage reports, etc. | H | ||||||
| Reporting | 9 | Reports | The system shall provide the functionality to create and maintain an updated data dictionary to help with reporting needs. | L | ||||||
| Reporting | 10 | Reports | The system shall support reporting on assets or records within a map-defined location or area (i.e. polygon). | L |
&G &"-,Bold"&18Reporting City of Austin
&"System Font,Regular"&10&K000000
B. Mobile
| System Functionality Category | ID | Type | Requirement | Priority (H, M, L) | Meets Requirement (Y/N) | (C)onfiguration, (A)Business Rule Automation, (B)oth, or (N)one | Customization (Y/N) | Future Product Release (Y/N) | Integration /w 3rd Party Product (Y/N) | Explanation/Comments |
| Mobile | 1 | Architecture | The mobile solution shall provide mobile access capabilities for staff use (e.g. Work Order , Service Request, and Inventory Management activities). | H | ||||||
| Mobile | 2 | Architecture | The mobile solution shall support iOS. | H | ||||||
| Mobile | 3 | Architecture | The mobile solution shall support Android. | H | ||||||
| Mobile | 4 | Architecture | The mobile solution shall provide the ability to diagnose mobile application and connectivity issues. | H | ||||||
| Mobile | 5 | Architecture | The mobile solution shall allow field staff to print via network connectivity, Airprint, and/or Bluetooth, including support for mobile printers. | H | ||||||
| Mobile | 6 | Document Management | The mobile solution shall have the ability to access, view, and edit documents/files. | H | ||||||
| Mobile | 7 | Document Management | The mobile solution shall support attaching images or videos via in-app capture without saving to device storage. | H | ||||||
| Mobile | 8 | Document Management | The mobile solution shall support the ability to download a construction plan in the field and markup or annotate the document/image within the app. | H | ||||||
| Mobile | 9 | Routing | The mobile solution shall have the ability to adjust the route based on real-time traffic information, priority of scheduled Work Orders and Service Request, or allow the staff member to change the route manually. | H | ||||||
| Mobile | 10 | GIS | The mobile solution shall support GIS-based mapping capabilities for work records and assets. | H | ||||||
| Mobile | 11 | GIS | The mobile solution shall support GIS features necessary for business operations in the field, such as the ability to select assets from a map and create work records or update asset information (i.e. valve open/close status). | H | ||||||
| Mobile | 12 | GIS | The mobile solution shall support zooming of the map to "My Location" of the mobile user in the field. | H | ||||||
| Mobile | 13 | GIS | The mobile solution shall display Asset/WO status and supporitng information by color codes or symbology | L | ||||||
| Mobile | 14 | GIS | The mobile solution shall support editing of non-authoritative GIS features (online or off-line where connectivity is unavailable) in the field. No editing of pre-existing authoritative GIS data within the application. | H | ||||||
| Mobile | 15 | Offline | The mobile solution shall provide the ability to operate in both online (with the available network) and offline mode (without a network, with automatic data synchronization when the network is available). Explain any loss of functionality/capability when working offline, if applicable. | H | ||||||
| Mobile | 16 | Offline | The mobile solution shall support defined queries to limit records downloaded based on the user's role/workgroup (i.e. only download records assigned to user and user's crew or workgroup) for full access to relevant work records in offline mode. | H | ||||||
| Mobile | 17 | Offline | The mobile solution shall not require online access to login to access downloaded inspections. | H | ||||||
| Mobile | 18 | Offline | The mobile solution shall be able to cache data if connectivity is temporarily lost while in the field. | H | ||||||
| Mobile | 19 | Usability | The mobile solution shall support text to speech capabilities where the text is input via the device microphone. | H | ||||||
| Mobile | 20 | Usability | The mobile solution shall have the ability to scan bar/QR codes/nfc tags to look up related record(s) and take action, input data, or search the system. | L | ||||||
| Mobile | 21 | Usability | The mobile solution shall allow supervisors the ability to manage field staff workload and mileage by monitoring work status and allowing the real-time update of WO/SR schedules. | H | ||||||
| Mobile | 22 | Usability | The mobile solution shall provide the ability to update multiple work records at one time. | H | ||||||
| Mobile | 23 | Usability | The mobile solution shall support global broadcast of messages to users/user groups. | L | ||||||
| Mobile | 24 | Usability | The mobile solution shall support searching, filtering, and sorting of all system configured record types (e.g., Assets, Positions, Work orders, Service Request, Inspections, Inventory etc.) including links to related data records. | H | ||||||
| Mobile | 25 | Usability | The mobile solution shall support the ability to text or communicate via the app. | L |
&G &"-,Bold"&18Reporting City of Austin
C. Portal
| System Functionality Category | ID | Type | Requirement | Priority (H, M, L) | Meets Requirement (Y/N) | (C)onfiguration, (A)Business Rule Automation, (B)oth, or (N)one | Customization (Y/N) | Future Product Release (Y/N) | Integration /w 3rd Party Product (Y/N) | Explanation/Comments |
| Portal | 1 | Architecture | The system shall provide three independent web portals that share the same back-end process workflows and configurations: (1) Staff portal that is not accessible by the public, (2) Contractor Portal (Only third party City contractors can use the portal) (3) Facilities portal (Internal building maintenance request portal) . Each portal would provide different levels of functionality and data access that is configurable. | H | ||||||
| Portal | 2 | Architecture | The system shall support all of the latest (and one version prior) desktop and mobile browsers (e.g., Edge, Firefox, Chrome, Safari, etc.) | H | ||||||
| Portal | 3 | Architecture | The system shall provide responsive design to support multiple display form factors (e.g., touch screen, mobile devices, desktop displays, etc.). | H | ||||||
| Portal | 4 | Architecture | The portal shall be HTTP 2.0 compliant | H | ||||||
| Portal | 5 | Architecture | The system shall maintain the any external web portal configurations and also provide backward compatibility after a product upgrade. | H | ||||||
| Portal | 6 | Architecture | The system shall provide and support RESTful services or API services that provide secure invoking and logging for invalid attempts. | H | ||||||
| Portal | 7 | Security | The system shall support the ability to restrict and/or disable external web portal access and display message during scheduled or unplanned maintenance windows. | H | ||||||
| Portal | 8 | Usability | The system shall provide navigation cues to guide users to where they are in the system. | H | ||||||
| Portal | 9 | Usability | The system shall comply with Web Content Accessibility Guidelines (WCAG) 2.0, Level AA and Section 508 compliant. | H | ||||||
| Portal | 10 | Usability | The system shall support multiple languages (e.g., English, Spanish, Mandarin, etc.). | H | ||||||
| Portal | 11 | Usability | The system shall provide consistent site navigation from page to page (e.g. use of sections and headers, location of menus, layout of buttons and other controls, etc.). | H | ||||||
| Portal | 12 | Usability | The system shall provide a clear navigation path that describes or illustrates where the user is located within the web portal (e.g., breadcrumbs, heading titles, etc.). | H | ||||||
| Portal | 13 | Usability | The system will provide the ability for the user to perform data entry tasks that minimize the use of a mouse (or pointing) device (e.g., tab sequencing of fields). | H | ||||||
| Portal | 14 | Usability | The system shall provide spell checking functionality of free-form text fields. | H | ||||||
| Portal | 15 | Usability | The system shall support robust search capabilities to locate information or data records quickly. | H | ||||||
| Portal | 16 | Usability | The system shall support the ability to display system-wide messages throughout any external web portal. | H | ||||||
| Portal | 17 | Preferences | The system shall allow the users to configure their view and save their preferences. | L | ||||||
| Portal | 18 | Preferences | The system shall allow users to set display preferences (e.g., language, font size, etc.) to improve application usability/accessibility. | L | ||||||
| Portal | 19 | Preferences | The system shall support user profiles that allow users to configure and save their system preferences to their user profile (e.g., user information, notification preferences, screen/table views, etc.). | L | ||||||
| Portal | 20 | Preferences | The system shall save user profile preferences and set automatically on login. | H | ||||||
| Portal | 21 | Online Help | The system shall provide instructions and help text at the screen and data field level. | H | ||||||
| Portal | 22 | Online Help | The system shall provide on line, interactive help with support for hyperlink technology and industry standard formats (e.g., .hlp or html file formats). | H | ||||||
| Portal | 23 | Online Help | The system shall provide an online knowledge base that allows customers to search and access answers to common questions or topics quickly. | L | ||||||
| Portal | 24 | Online Help | The system shall allow City staff to update content in the knowledge base through a change in configuration settings. | H | ||||||
| Portal | 25 | Help | The system shall have customizable online documentation and training materials such as context-specific help, search capability, organization-specific business process documentation and process maps. | L | ||||||
| Portal | 26 | Help | The system shall provide collaborative web browsing capability that allows staff to review the application as the customer completes it online. | H | ||||||
| Portal | 27 | Usability | The system shall support the uploads up to 512mb and meet City's data retention policies. | H | ||||||
| Portal | 28 | Usability | The system shall support multiple uploads per submission. | H | ||||||
| Portal | 29 | Usability | The system shall allow the user to access and sort (across multiple criteria) all records tied to their user account. | H | ||||||
| Portal | 30 | Usability | The system shall allow the user to grant other parties access to select records tied to their user account. | L |
&G &"-,Bold"&18Reporting City of Austin
D. GIS
| System Functionality Category | ID | Type | Requirement | Priority (H, M, L) | Meets Requirement (Y/N) | (C)onfiguration, (A)Business Rule Automation, (B)oth, or (N)one | Customization (Y/N) | Future Product Release (Y/N) | Integration /w 3rd Party Product (Y/N) | Explanation/Comments |
| GIS | 1 | GIS | The system shall provide the ability to use the AW's existing connectivity stored within the GIS with full current ESRI functionality to avoid redundant/unnecessary data entry or data conversion in Map view (includes existing networks and polygons). | H | ||||||
| GIS | 2 | GIS | The system shall provide the ability to access GIS data in all functional areas of the systems (including mobile applications). | H | ||||||
| GIS | 3 | GIS | The system shall provide the ability to edit ancillary GIS data via access within the system. It shall prevent the editing of pre-existing authoritative GIS data. Please describe how your system supports this requirement. | H | ||||||
| GIS | 4 | GIS | The system shall provide the ability to assign user and/or user group permissions to GIS map features, functionality (e.g. adding layers, changing external/internal visibility etc.), and services (e.g. make the map available from the GIS system to the CMMS System, etc.). | H | ||||||
| GIS | 5 | GIS | The system shall have the capability to access GIS data for offline use and synchronize updates when connectivity is restored. | H | ||||||
| GIS | 6 | GIS | The system shall have the ability to search, retrieve, and assign asset data and other GIS features from AW's authoritative GIS system. | H | ||||||
| GIS | 7 | GIS | The system shall have the ability to display asset location on a map based on GIS location or coordinates. | H | ||||||
| GIS | 8 | GIS | The system shall allow the user to identify on a map the location for a service request or work order by address or associated asset's location. | H | ||||||
| GIS | 9 | GIS | The system shall validate addresses against the City's authoritative GIS. | H | ||||||
| GIS | 10 | GIS | The system shall have the ability to select map objects and retrieve and overlay data attribute information from GIS (i.e. pressure zones). | H | ||||||
| GIS | 11 | GIS | The system shall support geographical proximity alerts that check geographical surroundings to inform whether or not an open work record for a similar problem already exists within the system (based on specific business rules). Please describe how your systems calculate the proximity. The proximity alerts shall work from map created or system created work records. | H | ||||||
| GIS | 12 | GIS | The system shall be capable of displaying a map customized by user roles and permissions for various user roles (e.g., meter technician, valve crew). | H | ||||||
| GIS | 13 | GIS | The system shall have the ability to display assets/work records on a map based on user-defined search criteria (e.g., display all active leak response SR/WOs). | H | ||||||
| GIS | 14 | GIS | The system shall support geospatial querying and display results in a map view. | H | ||||||
| GIS | 15 | GIS | The system shall support the ability to display saved query results in a map view. | H | ||||||
| GIS | 16 | GIS | The system shall provide the ability for users to zoom in/out and pan in Map view. | H | ||||||
| GIS | 17 | GIS | The system shall provide the ability to display and symbolize GIS asset features (e.g., valves, hydrants, mains) based on unique attribute values or value ranges (e.g., pipe diameter, installation year, status). | H | ||||||
| GIS | 18 | GIS | The system shall provide the ability to perform basic map viewing functions including display, drill-down, query, and analyze dynamic map data in Map view. | H | ||||||
| GIS | 19 | GIS | The system shall provide the ability to print maps in Map view and export to a City template (E.g., convert to PDF and share via an email or internal message). | H | ||||||
| GIS | 20 | GIS | The system shall allow for point-and-click and area sketch location selection for service events that do not directly correspond to an address (e.g. the user draws a polygon on the map to indicate the area for a follow-up etc.). | H | ||||||
| GIS | 21 | GIS | The system shall allow user to add comments and determine the scale when printing GIS maps. | H | ||||||
| GIS | 22 | GIS | The system shall allow for a customer to upload AutoCAD data for plans and have it converted to GIS, based on business rules | L | ||||||
| GIS | 23 | GIS | The system shall support the ability to load, manage, and interact with 150 or more GIS layers from Austin Water’s authoritative asset-based GIS. The system shall allow users to toggle visibility, query, and analyze these layers without performance degradation. | H | ||||||
| GIS | 24 | GIS | The system shall support the ability to define geographic zones and assign specific techs or crews for response. | L | ||||||
| GIS | 25 | GIS | The system shall be able to consume AW's authoritative GIS data in real time. Please define "real time". | H | ||||||
| GIS | 27 | GIS | The system shall allow user to initiate/create work records or projects based on a selection of one or multiple assets/locations from authoritative GIS data. | H | ||||||
| GIS | 28 | GIS | The system shall provide the ability for a user to select multiple GIS map features using a 'select by attribute' function. | H | ||||||
| General | 29 | GIS | The system shall have the ability to ingest geospatial data, set as a target layer by the user, to select and/or query geospatial information. (for example, a user can identify a target source of geospatial data to perform a select by location query). | H | ||||||
| General | 30 | GIS | The system shall support GIS (ESRI-based) as the authoritative system of record for spatial asset data. | H | ||||||
| General | 31 | GIS | The system shall support automated, bidirectional synchronization between GIS and CMMS databases. | H | ||||||
| General | 32 | GIS | The system shall provide configurable field-level mapping between GIS and CMMS data models. | H | ||||||
| General | 33 | GIS | The system shall support configurable synchronization rules (e.g., overwrite, append, ignore) for each mapped field. | H | ||||||
| General | 34 | GIS | The system shall include attribute locking mechanisms to prevent unauthorized or unintended data overwrites. | H | ||||||
| General | 35 | GIS | The system shall allow administrators to define and manage the system of record per data domain (e.g., assets, work orders). | H | ||||||
| General | 36 | GIS | The system shall support real-time or near real-time updates for key operational data (e.g., asset status, work order status). | H | ||||||
| General | 37 | GIS | The system shall provide detailed documentation of the integration framework, including data flow diagrams and field-level mappings. | H | ||||||
| General | 38 | GIS | The system shall include a user-friendly interface for managing and updating data mappings between GIS and CMMS. | H | ||||||
| General | 39 | GIS | The system shall be compatible with ESRI’s Utility Network model. | H | ||||||
| General | 40 | GIS | The system shall be able to consume GIS data via ESRI services (e.g., feature services, map services, geoprocessing services) in both desktop and mobile platforms. | H | ||||||
| General | 41 | GIS | The system shall support network-aware asset management, including tracing and connectivity modeling. | H | ||||||
| General | 42 | GIS | The system shall support capture and storage of GPS coordinates (X, Y, Z) for assets and work orders. | H | ||||||
| General | 43 | GIS | The system shall support coordinate capture via both GIS interface and mobile application. | H | ||||||
| General | 44 | GIS | The system shall support state plane coordinate systems and allow configuration of coordinate formats. | H | ||||||
| General | 45 | GIS | The system shall support role-based access control for GIS-integrated data and synchronization settings. | H | ||||||
| General | 46 | GIS | The system shall provide audit logging for all synchronization activities, including user, timestamp, and source system. | H | ||||||
| General | 47 | GIS | The system shall be scalable to support large datasets and frequent updates without performance degradation. | H | ||||||
| General | 48 | GIS | The system shall support the ability to promote or deploy approved GIS-related configurations, custom map layers, data integrations, and workflow automations from lower environments (e.g., development or testing) to higher environments (e.g., staging or production) in a controlled and auditable manner without duplication of effort. | H |
&G &"-,Bold"&18Reporting City of Austin
E. General Technology
| System Functionality Category | ID | Type | Requirement | Priority (H, M, L) | Meets Requirement (Y/N) | (C)onfiguration, (A)Business Rule Automation, (B)oth, or (N)one | Customization (Y/N) | Future Product Release (Y/N) | Integration /w 3rd Party Product (Y/N) | Explanation/Comments |
| General Technology | 1 | Application | The system shall be a web-based application with logical and physical separation of the presentation, business logic, and data layers. | H | ||||||
| General Technology | 2 | Application | The system shall provide a fault-tolerant, redundant, and scalable architecture, supporting high availability (99.9% SLA). | H | ||||||
| General Technology | 3 | Application | The system shall support session management across a web server load-balanced environment. | H | ||||||
| General Technology | 4 | Application | The system shall provide scalable document and content storage, with integrated or external DMS support (e.g., SharePoint, OpenText). | H | ||||||
| General Technology | 5 | Application | The system shall accommodate background (batch) jobs concurrently with online updates. | H | ||||||
| General Technology | 6 | Application | The system shall provide a comprehensive solution that minimizes reliance on third-party products, except where industry standards apply (e.g., ESRI, Power BI,). Vendor shall support any required products. | H | ||||||
| General Technology | 7 | Document Management | The system shall provide an integrated document management solution, with metadata, versioning, and retention controls. | H | ||||||
| General Technology | 8 | Configuration Mgmt | The system shall provide configurable processes and rule automation, defined once and shared across portals, staff, and mobile devices. | H | ||||||
| General Technology | 9 | Workflow Mgmt | The system shall support a business process flow tool enabling administrators to graphically design workflows. | H | ||||||
| General Technology | 10 | Database | The system shall support multiple database instances (SQL Server preferred) and store all data in a centralized repository. | H | ||||||
| General Technology | 11 | Security | The system shall enforce role-based access control (RBAC), multi-factor authentication (MFA), and comply with NIST, SOC2, ISO 27001. | H | ||||||
| General Technology | 12 | Security | The system shall encrypt all data in transit (TLS 1.3+) and at rest (AES-256 minimum), with full audit logging of user activity and system changes. | H | ||||||
| General Technology | 13 | Error Handling | The system shall log all errors (with severity, timestamp, codes), generate configurable end user error messages (without sensitive data), and notify admins for critical issues. | H | ||||||
| General Technology | 14 | Infrastructure | The vendor shall provide multiple environments (dev, test/training, production) and support upgrades without requiring reconfiguration. | H | ||||||
| General Technology | 15 | Integration & APIs | The system shall provide a secure library of RESTful APIs (CRUD), support consuming external APIs, integrate with data warehouses (ETL real time/batch), and comply with Open Data standards. | H | ||||||
| General Technology | 16 | Integration & APIs | The system shall support SSO via Azure AD, SAML 2.0, or OAuth 2.0 identity providers. | H | ||||||
| General Technology | 17 | Performance | The system shall monitor/display online users, uptime, transaction response times (≤3 sec), and support scaling to up to 500+ concurrent users. | H | ||||||
| General Technology | 18 | Performance | The system shall be accessible 24/7 (outside planned maintenance) and support 500+ concurrent mobile users on public cell networks (4G/LTE/5G). | H | ||||||
| General Technology | 19 | Disaster Recovery | The system shall provide automated backups (incremental & daily), geo-redundant storage, and meet MAC1 RTO ≤ 2 hours and RPO - zero data loss | H | RTO = Recovery Time Objective, RPO = Recovery Point Objective | |||||
| General Technology | 20 | Records & Retention | The system shall support data lifecycle, archival, retention, legal holds, and disposition per Austin City Code §2-11-11 and Texas Local Gov. Records Act, with audit logs of disposition. | H | ||||||
| General Technology | 21 | Usability | The system shall comply with WCAG 2.1 accessibility standards across all user facing interfaces. | H | ||||||
| General Technology | 22 | Notifications | The system shall provide configurable notification services (email, SMS, push) with templated messages pulling data from the system. | M | ||||||
| General Technology | 23 | Analytics / AI | The system shall support predictive analytics, AI/ML-driven insights (e.g., condition forecasting, anomaly detection, resource optimization). | M | ||||||
| General Technology | 24 | Data Center | For cloud based SaaS solutions, data centers must reside in contiguous US only. | H |
&G &"-,Bold"&18Reporting City of Austin
F. Systems- Interfaces System Functionality Category and ID Number
| Functional Category | Type | Requirement | (I)nterface, (R)eplace, (E)ither | Real-Time or Batch | One-Way or Two-Way | Priotity: (H)igh, (L)ow | AW Comments | Do you have experience implementing same/similar integration? Yes/No | Does your solution have an out of the box integration/connector? Yes/No | Does your solution require a custom integration? Yes/No | Are you a preferred integration partner? Yes/No | Explanation/Comments | |
| Interface | 1 | Inspection | Granite Net | Two way integration between Asset Management System and GraniteNet Cloud leveraging COA's preferred middleware. Preferred: First tier partner integration incorporating automated scheduler. | I | B | 2 | H | GraniteNet is the next-generation infrastructure inspection and decision support software for water, wastewater and municipal public works asset management. Whether used in the field on tablets or via a web browser to review and analyze inspections, GraniteNet embraces the Cloud for media storage while enabling simple, precise data collection with integrated GIS mapping and GPS. | ||||
| Interface | 2 | Asset Management | Maximo | Two way integration between AW's Asset Management System and Maximo, used by other COA departments, to facilitate collaboration by passing work assignments and completion information between the two systems. | I | B | H | ||||||
| Interface | 3 | Sign on | AD MSFT | Application should be able to able to integrate with Microsoft Active Directory via SAM ID for log in and authentication | I | R | 2 | H | |||||
| Interface | 4 | Meter Readings | AclaraOne | Support creation of Service Requests or Work Orders based on Event Alerts from AclaraOne, AW's AMI system. | I | B | 1 | H | Advanced metering infrastructure (AMI) technologies allow water utilities to tackle issues like theft, unmeasured water usage, inaccurate meters, and leaks, helping them recover lost revenue. Aclara provides the necessary data and advanced applications that utilities need to make the most of their AMI investments, enhance their services, and better manage their water distribution networks | ||||
| Interface | 5 | Asset Management | Amanda | Two way integration to create Permit Requests in AMANDA and to return permit information to the Asset Management System. Additionally, create service lines in the Asset Management System based on approved Tap Permits in AMANDA. | I | B | 2 | H | |||||
| Interface | 6 | Customer & Service Manamgenet | Salesforce | Two way integration supporting case management in Salesforce linked to multiple Service Requests in the Asset Management System. Ability to create new Service Requests in the Asset Management System from a case in Salesforce. |
| One way data load of Asset and Service Request records from the Asset Management System to Salesforce. | I | R | 2 | H | |
| Interface | 7 | Customer & Service Manamgenet | Motorola CSR 311 Intake | Motorola CSR is a system leveraged by the City of Austin's 311 department for citizen issue reporting. The City intends to have a two-way interface with the 311 solution to support the intake and management of issues/complaints. |
System shall verify addresses from 311 against GIS data and flag for discrepancies. 311 must have the abiilty cross reference City GIS data prior to issuing inspection base on an issue filed with 311.
| When the same issue is reported in 311 in multiple times, the duplicate reports are added to the existing open SR in CMMS as additional callers rather than creating duplicate SRs in CMMS | I | R | 1 | H | |||||
| Interface | 8 | Customer Care & Billing | CC&B | All AW billing is completed through CC&B. Integration required to sync asset data between the systems, update meter/register assets, send meter read data, and to complete field activities initiated from CC&B, creating a Service Request in the Asset Management System. | I | R | 2 | H | |
| Interface | 9 | GIS | GIS - ESRI | AW requires compatibility with ESRI Utility Network. |
Required GIS version compatibility: The system shall maintain versions relevant to industry standards and Esri support models.
This data shall be integrated in "real-time" via API, in less than 15 mins. The integration should support two-way data sync while restricting overwriting of GIS authoritative fields.
System should store x,y,z coordinates - for ease of extraction.
System must have the ability to support viewing and analysing 150+ layers from authoritative GIS data sources.
| I | R | 2 | H | |||||
| Interface | 10 | Datawarehouse | All data needs to be sync with current data warehouse systems in near real time to support AW's reporting needs | I | B | 1 | H |
&G &"-,Bold"&18Reporting City of Austin
Data Migration Scope Matrix
| Data Area | Migration Method | Assumptions / Limitations |
| Asset Master Data | ||
| Asset Hierarchy / Locations | ||
| Work Orders | ||
| Work Order History | ||
| Preventive Maintenance Records | ||
| Inspections | ||
| Inventory / Materials | ||
| Labor / Crew Data | ||
| Documents / Attachments | ||
| GIS Related Asset Data | ||
| User / Role Data | ||
| Reports / Dashboards |
| Data Migration Approach Response |
| Vendor shall describe how it will plan, execute, validate, and support data migration from legacy systems into the proposed solution. |
| Vendor Response: |
| [Insert response here] |
image1.png image2.png
File details come from the government source that posted it. Updated .