Requirements_-_OPS_Assessment_Project.xlsx
XLSX spreadsheet 54 KB Posted
- Attached to
- Permitting and Land Management Software
- Solicitation number
- RFP195677
- Issued by
- Santa Clara County, California
About this file
The document is a comprehensive Requirements spreadsheet for a Permitting and Land Management Software RFP from the City of Palo Alto's Planning & Development Services Department. The city is seeking a cloud-based permitting system to replace its current platform, with proposals due by November 11, 2025 at 3:00 pm PST. The project aims to support permitting, land management, code enforcement, and inspections functions, with an anticipated project timeline including vendor interviews in December 2025 - January 2026, intent to award in March 2026, project initiation in April 2026, and a targeted go-live in September 2027 or earlier. The system will support up to 200 user licenses and requires comprehensive capabilities including dynamic form processing, online permit applications, real-time status tracking, document management, fee calculations, mobile inspection support, and integration with existing city systems like ArcGIS and Azure Entra ID.
The RFP emphasizes the need for a collaborative, scalable solution with strong security features and robust support capabilities. While specific budget details are not explicitly stated, the procurement will require one-time implementation expenses and ongoing annual SaaS licensing, hosting, maintenance, and training costs. The vendor must manage a data migration covering 42 years of historical records and provide 60 days of post-go-live support. Key integration requirements include interfaces with systems such as Power BI, DigEplan, ArcGIS Enterprise, PublicStuff, California State License Board, SolarAPP+, Elevon Converge payment gateway, and Microsoft technologies. The city seeks a vendor who can demonstrate proven expertise in permitting functions, commitment to collaboration, scalability, security, and innovation to meet evolving technological and community needs.
View the file
Other files
Show all 29
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
Requirements
| ID | ID1 | ID2 | Requirement Type | Subtype | Requirement | Priority | Vendor Response | Vendor Notes | City of Palo Alto Notes |
| 0.0 | 0 | 0 | Demo | ||||||
| 0.1 | 0 | 1 | Non-functional | Demo | Vendor shall provide a sandbox environment to the evaluation team for hands-on demo and trial of solution | Nice to have | |||
| 1.0 | 1 | 0 | Permitting - Application Intake | ||||||
| 1.1 | 1 | 1 | Functional | Permitting - Application Intake | When staff fills out address or parcel information, system shall search an APO GIS database to validate the input | Mandatory | |||
| 1.2 | 1 | 2 | Functional | Permitting - Application Intake | System shall automatically issue permits if specific, pre-determined criteria are met | Mandatory | |||
| 1.3 | 1 | 3 | Functional | Permitting - Application Intake | System shall implement data quality checks and validation rules to ensure accuracy, completeness, and consistency of data. Exceptions or data errors should trigger alerts and corrective workflows | Mandatory | |||
| 1.4 | 1 | 4 | Functional | Permitting - Application Intake | System shall allow for seamless transition from preapplication record flow to application record to final | Nice to have | |||
| 2.0 | 2 | 0 | Permitting - General | ||||||
| 2.1 | 2 | 1 | Functional | Permitting - General | System shall allow administrators the ability to create new application types for different functional areas, including but not limited to Planning, Building, Fire, Public Works, Utilities, Transportation, and Code Enforcement | Mandatory | |||
| 3.0 | 3 | 0 | Permitting - Land Management | ||||||
| 3.1 | 3 | 1 | Functional | Permitting - Land Management | System shall maintain relationships between old and new addresses and parcels through time | Nice to have | |||
| 4.0 | 4 | 0 | Permitting - Status | ||||||
| 4.1 | 4 | 1 | Functional | Permitting - Status | System shall track application status in real-time | Mandatory | |||
| 4.2 | 4 | 2 | Functional | Permitting - Status | System shall stamp key permit process milestones with the date / time (e.g., application received, completeness check, plan review completed, inspections scheduled) | Mandatory | |||
| 4.3 | 4 | 3 | Functional | Permitting - Status | System shall allow configurable statuses with corresponding actions for workflow, records, and inspections | Mandatory | |||
| 5.0 | 5 | 0 | Permitting - Workflow | ||||||
| 5.1 | 5 | 1 | Functional | Permitting - Workflow | System shall assign applications to appropriate staff | Mandatory | |||
| 5.1 | 5 | 1 | Functional | Permitting - Workflow | System shall allow reviewers to approve, deny, or request corrections with comments | Mandatory | |||
| 5.2 | 5 | 2 | Functional | Permitting - Workflow | System shall show a clear history of a project's workflow that can be easily audited, including date and time of activity | Mandatory | |||
| 5.3 | 5 | 3 | Functional | Permitting - Workflow | System shall provide administrators ability to audit workflow changes and changes to custom fields | Mandatory | |||
| 5.4 | 5 | 4 | Functional | Permitting - Workflow | When a staff determines a form is needed, they check a box in workflow, and the system generates a pre-filled form, notifies the applicant, and the applicant completes the form online that updates fields on the record and is uploaded to the records documents. | Nice to have | |||
| 5.5 | 5 | 5 | Functional | Permitting - Workflow | System shall automatically move permits forward based on completion of workflow steps or ability to remove or skip work workflow steps for a specific permit. | Mandatory | |||
| 5.6 | 5 | 6 | Functional | Permitting - Workflow | System shall allow a customization of due dates by record type, workflow, task, and custom fields. | Mandatory | |||
| 5.7 | 5 | 7 | Functional | Permitting - Workflow | System shall take working days, holidays, and periodic shutdowns into account and automatically updating workflow due dates | Mandatory | |||
| 5.8 | 5 | 8 | Functional | Permitting - Workflow | System shall support configurable, multi-step approval workflows per permit type | Mandatory | |||
| 5.9 | 5 | 9 | Functional | Permitting - Workflow | System shall support conditional routing based on application content | Mandatory | |||
| 6.0 | 6 | 0 | Applicant Portal - Baseline Functionality | ||||||
| 6.1 | 6 | 1 | Functional | Applicant Portal - Baseline Functionality | Apply for a permit using dynamic guided forms based on permit type | Mandatory | |||
| 6.1 | 6 | 1 | Functional | Applicant Portal - Baseline Functionality | Sign in, authenticate, and have more services available | Mandatory | |||
| 6.2 | 6 | 2 | Functional | Applicant Portal - Baseline Functionality | Save progress and resume drafts | Mandatory | |||
| 6.3 | 6 | 3 | Functional | Applicant Portal - Baseline Functionality | Submit applications and receive confirmation and record ID number | Mandatory | |||
| 6.4 | 6 | 4 | Functional | Applicant Portal - Baseline Functionality | Make a payment | Mandatory | |||
| 6.5 | 6 | 5 | Functional | Applicant Portal - Baseline Functionality | View fees due | Mandatory | |||
| 6.6 | 6 | 6 | Functional | Applicant Portal - Baseline Functionality | Schedule, view, and cancel inspections | Mandatory | |||
| 6.7 | 6 | 7 | Functional | Applicant Portal - Baseline Functionality | Create an account using email, phone number, or username | Mandatory | |||
| 6.8 | 6 | 8 | Functional | Applicant Portal - Baseline Functionality | Update personal and contact details | Mandatory | |||
| 6.9 | 6 | 9 | Functional | Applicant Portal - Baseline Functionality | Self-serve password reset function | Mandatory | |||
| 6.1 | 6 | 11 | Functional | Applicant Portal - Baseline Functionality | Download and upload documents in various formats | Mandatory | |||
| 6.1 | 6 | 12 | Functional | Applicant Portal - Baseline Functionality | Display content in multiple-languages, including Spanish, Simplified Chinese, and Korean | Mandatory | |||
| 6.1 | 6 | 13 | Functional | Applicant Portal - Baseline Functionality | Verify account creation via email or SMS | Nice to have | |||
| 6.1 | 6 | 14 | Functional | Applicant Portal - Baseline Functionality | Ability to include different stakeholders such as property owner, contractor, architect, and tennant as contacts on the record with varying permission levels | Nice to have | |||
| 7.0 | 7 | 0 | Applicant Portal - Map View | ||||||
| 7.1 | 7 | 1 | Functional | Applicant Portal - Map View | System shall show public-users a map of permits and permit applications that allows them to search by address or a unique identifier (i.e., permit number) and pan the map. | Nice to have | Similarly to Buildingeye | ||
| 8.0 | 8 | 0 | Applicant Portal - Editing Portal | ||||||
| 8.1 | 8 | 1 | Functional | Applicant Portal - Editing Portal | System shall support editing of the public-facing website by staff users | Mandatory | |||
| 8.2 | 8 | 2 | Functional | Applicant Portal - Editing Portal | System shall show notifications to public users as configured by staff users for sharing of updates and service impacts | Mandatory | |||
| 9.0 | 9 | 0 | Applicant Portal - Form and Document Validation | ||||||
| 9.1 | 9 | 1 | Functional | Applicant Portal - Form and Document Validation | When applicant fills out address or parcel information, system shall search an APO GIS database to validate the input | Mandatory | |||
| 9.2 | 9 | 2 | Functional | Applicant Portal - Form and Document Validation | System shall implement data quality checks and validation rules to ensure accuracy, completeness, and consistency of data. Exceptions or data errors should trigger alerts and corrective workflows | Mandatory | |||
| 9.3 | 9 | 3 | Functional | Applicant Portal - Form and Document Validation | System shall perform advanced document checking using AI technologies and review for completeness, consistency, and metadata | Nice to have | |||
| 10.0 | 10 | 0 | Applicant Portal - UI/UX | ||||||
| 10.1 | 10 | 1 | Functional | Applicant Portal - UI/UX | For the public-facing website, system shall have modern and contemporary design and UI/UX | Mandatory | |||
| 10.2 | 10 | 2 | Functional | Applicant Portal - UI/UX | System shall use a responsive design to fit on multiple screen sizes | Mandatory | |||
| 11.0 | 11 | 0 | Documents | ||||||
| 11.1 | 11 | 1 | Functional | Documents | System shall provide a document management system within the software. | Mandatory | |||
| 11.2 | 11 | 2 | Functional | Documents | System shall provide parent/child connections between document versions (i.e., version control) | Mandatory | |||
| 11.3 | 11 | 3 | Functional | Documents | System shall back-up documents every 24 hours in case of accidental document loss. | Mandatory | |||
| 11.4 | 11 | 4 | Functional | Documents | System shall generate approval documents and letters based on standard and custom fields | Mandatory | |||
| 11.5 | 11 | 5 | Functional | Documents | System shall allow configurable metadata such as document types | Mandatory | |||
| 12.0 | 12 | 0 | Fees and Payments - Schedule and Assessment | ||||||
| 12.1 | 12 | 1 | Functional | Fees and Payments - Schedule and Assessment | Enter and store the municipal fee schedule in a dynamic and programmatic way | Mandatory | |||
| 12.2 | 12 | 2 | Functional | Fees and Payments - Schedule and Assessment | Support multiple fee schedules to accommodate different departments or functional areas | Mandatory | |||
| 12.3 | 12 | 3 | Functional | Fees and Payments - Schedule and Assessment | Version control for fee schedules to track changes over time and maintain historical records | Mandatory | |||
| 12.4 | 12 | 4 | Functional | Fees and Payments - Schedule and Assessment | System shall allow users to manually add fees | Mandatory | |||
| 12.5 | 12 | 5 | Functional | Fees and Payments - Schedule and Assessment | System shall support automated fee assessment logic | Mandatory | |||
| 12.6 | 12 | 6 | Functional | Fees and Payments - Schedule and Assessment | System shall support automated fee adjustments based on specific conditions | Mandatory | |||
| 13.0 | 13 | 0 | Fees and Payments - Fee Calculation | ||||||
| 13.1 | 13 | 1 | Functional | Fees and Payments - Fee Calculation | System shall calculate fees based on defined criteria, such as project valuation, square footage, or other quantifiable metrics | Mandatory | |||
| 13.2 | 13 | 2 | Functional | Fees and Payments - Fee Calculation | System shall provide a development impact fee calculator | Mandatory | |||
| 14.0 | 14 | 0 | Fees and Payments - Adjustments and Refunds | ||||||
| 14.1 | 14 | 1 | Functional | Fees and Payments - Adjustments and Refunds | System shall have the ability to adjust fees post-assessment if errors are identified or if project parameters change | Mandatory | |||
| 14.2 | 14 | 2 | Functional | Fees and Payments - Adjustments and Refunds | System shall have the ability to process fee refunds with an audit trail for transparency and accountability | Mandatory | |||
| 15.0 | 15 | 0 | Fees and Payments - Payments | ||||||
| 15.1 | 15 | 1 | Functional | Fees and Payments - Payments | System shall allow online payment via credit or debit card, ACH, or other configured methods | Mandatory | |||
| 15.2 | 15 | 2 | Functional | Fees and Payments - Payments | If a customer wishes to make a payment in person, system shall facilitate in-person payments by a user | Mandatory | |||
| 15.3 | 15 | 3 | Functional | Fees and Payments - Payments | System shall generate payment receipts and link them to the permit record | Mandatory | |||
| 16.0 | 16 | 0 | Inspections | ||||||
| 16.1 | 16 | 1 | Functional | Inspections | System shall support bulk assignments of inspections | Nice to have | |||
| 16.2 | 16 | 2 | Functional | Inspections | System shall have the ability to log inspection results in the field using a smartphone or tablet including photo uploads, inspection comments, and other information | Mandatory | |||
| 16.3 | 16 | 3 | Functional | Inspections | System shall provide administrators ability to audit changes to inspections | Mandatory | |||
| 16.4 | 16 | 4 | Functional | Inspections | When inspector devices have poor or no connectivity, the system shall support offline functionality and resync data such as form fields, photos, inspection results, comments, and other information with the database when the device has a better connection | Mandatory | |||
| 16.5 | 16 | 5 | Functional | Inspections | System shall offer users the ability to schedule, modify, or cancel inspections | Mandatory | |||
| 16.6 | 16 | 6 | Functional | Inspections | System shall limit the number of inspections on any given day | Mandatory | |||
| 16.7 | 16 | 7 | Functional | Inspections | System shall not allow inspections to be scheduled on City holidays or other configurable days when inspection services are unavailable | Mandatory | |||
| 17.0 | 17 | 0 | Interfacing | ||||||
| 17.1 | 17 | 1 | Functional | Interfacing | System shall interface with Power BI and other business analytics platforms for advanced reporting and dashboarding, both internal and public-facing | Mandatory | |||
| 17.2 | 17 | 2 | Functional | Interfacing | System shall interface and integrate with DigEplan, Bluebeam, or other electronic plan review software | Mandatory | |||
| 17.3 | 17 | 3 | Functional | Interfacing | System shall integrate with the City’s ArcGIS Enterprise environment by consuming Esri Map and/or Feature Services to support GIS data and mapping functionality | Mandatory | |||
| 17.4 | 17 | 4 | Functional | Interfacing | System shall interface with PublicStuff for code enforcement cases | Mandatory | |||
| 17.5 | 17 | 5 | Functional | Interfacing | System shall interface with Laserfiche for file storage and retrieval | Nice to have | |||
| 17.6 | 17 | 6 | Functional | Interfacing | System shall interface with the California State License Board to validate credentials of licensed professionals | Mandatory | |||
| 17.7 | 17 | 7 | Functional | Interfacing | System shall interface with SolarAPP+ to streamline residential solar permitting | Nice to have | |||
| 17.8 | 17 | 8 | Functional | Interfacing | System shall interface with City's payment gateway and processor, Elevon Converge | Mandatory | |||
| 17.9 | 17 | 9 | Functional | Interfacing | System shall interface with the City's inspections scheduling and inspector app provided by CityGovApp | Mandatory | Mandatory unless alternative is provided within solution. | ||
| 17.10 | 17 | 10 | Functional | Interfacing | System shall interface with Microsoft Bookings and Outlook for appointment scheduling | Nice to have | Alternatively, solution could offer similar functionality built-in. | ||
| 17.11 | 17 | 11 | Functional | Interfacing | System shall interface with DocuSign for e-signatures | Nice to have | Alternatively, solution could offer similar functionality built-in. | ||
| 17.12 | 17 | 12 | Functional | Interfacing | System shall interface with Azure Entra ID to enable account creation, user provisioning, authentication, and role-based access control | Mandatory | |||
| 18.0 | 18 | 0 | Notifications | ||||||
| 18.1 | 18 | 1 | Functional | Notifications | System shall send automated emails at customizable trigger points to dynamic groups or individuals with customizable and dynamic content | Mandatory | |||
| 18.2 | 18 | 2 | Functional | Notifications | System shall send automated texts at customizable trigger points to dynamic groups or individuals with customizable and dynamic content | Nice to have | |||
| 18.3 | 18 | 3 | Functional | Notifications | System shall display previous notifications to users internally | Mandatory | |||
| 18.4 | 18 | 4 | Functional | Notifications | System shall display previous notifications to users on the public-facing website | Nice to have | |||
| 18.5 | 18 | 5 | Functional | Notifications | System shall support a centralized notification management system that allows tracking and management of all communications in one place | Mandatory | |||
| 19.0 | 19 | 0 | Reporting | ||||||
| 19.1 | 19 | 1 | Functional | Reporting | System shall let users publish reports to public-facing portal | Mandatory | |||
| 19.2 | 19 | 2 | Functional | Reporting | System shall let users create reports on-the-fly | Mandatory | |||
| 19.3 | 19 | 3 | Functional | Reporting | System shall visualize task management and workflow assignments data to users through dashboards | Mandatory | |||
| 19.4 | 19 | 4 | Functional | Reporting | System shall have the ability to send out auto-generated and emailed reports to staff | Mandatory | |||
| 19.5 | 19 | 5 | Functional | Reporting | System shall generate report documents based on standard and custom fields, triggered manually or automatically | Mandatory | |||
| 19.6 | 19 | 6 | Functional | Reporting | System shall support exporting reports and data into CSV, Excel, Word, PDF or other formats | Mandatory | |||
| 20.0 | 20 | 0 | System Admin | ||||||
| 20.1 | 20 | 1 | Functional | System Admin | System shall support role-based permissions | Mandatory | |||
| 20.2 | 20 | 2 | Functional | System Admin | System shall allow only users with the Administrator role to create or delete user accounts | Mandatory | |||
| 20.3 | 20 | 3 | Functional | System Admin | System shall allow access to documents based on user roles and document types or categories | Mandatory | |||
| 20.4 | 20 | 4 | Functional | System Admin | System shall allow administrators to manage passwords for system and public users. | Mandatory | |||
| 20.5 | 20 | 5 | Functional | System Admin | System shall support fine-grained access controls that go beyond role-based access, enabling permissions at the data field, transaction, and document levels in accordance with user-specific needs and security requirements | Mandatory | |||
| 20.6 | 20 | 6 | Functional | System Admin | System shall log all system admin activities. | Mandatory | |||
| 20.7 | 20 | 7 | Functional | System Admin | System shall provide administrators ability to audit changes to documents. | Mandatory | |||
| 20.8 | 20 | 8 | Functional | System Admin | System shall provide comprehensive logging and auditing capabilities for all user interactions and modifications of data, allowing administrators to monitor compliance and data handling practices | Mandatory | |||
| 20.9 | 20 | 9 | Functional | System Admin | System shall allow system admins to create custom record types, workflows, data fields, and functional areas using a user-friendly interface and templates to reduce reliance on technical third-party specialists | Mandatory | |||
| 21.0 | 21 | 0 | User Experience | ||||||
| 21.1 | 21 | 1 | Functional | User Experience | System shall show users their tasks | Mandatory | |||
| 21.2 | 21 | 2 | Functional | User Experience | System shall provide low-code or no-code interface for system admins to modify workflows, data fields, record types, or functional areas | Nice to have | |||
| 22.0 | 22 | 0 | Testing and Training | ||||||
| 22.1 | 22 | 1 | Non-functional | Testing and Training | Training curriculum for end-users | Mandatory | |||
| 22.2 | 22 | 2 | Non-functional | Testing and Training | Training curriculum for administrators | Mandatory | |||
| 22.3 | 22 | 3 | Non-functional | Testing and Training | Training or outreach resources for applicants | Nice to have | |||
| 22.4 | 22 | 4 | Non-functional | Testing and Training | Post training support and documentation | Mandatory | |||
| 22.5 | 22 | 5 | Non-functional | Testing and Training | Curriculum for UAT | Mandatory | |||
| 22.6 | 22 | 6 | Non-functional | Testing and Training | The vendor shall provide UAT test scripts | Mandatory | |||
| 22.7 | 22 | 7 | Non-functional | Testing and Training | Vendor shall provide a point of contact for training follow-up | Mandatory | |||
| 22.8 | 22 | 8 | Non-functional | Testing and Training | Vendor shall provide sandbox or testing environments to safely explore new configurations without affecting live data | Mandatory | |||
| 23.0 | 23 | 0 | Data Conversion / Migration | ||||||
| 23.1 | 23 | 1 | Non-functional | Data Conversion / Migration | Historical data, going back 42 years, will be imported to the new system | Mandatory | |||
| 23.2 | 23 | 2 | Non-functional | Data Conversion / Migration | Vendor shall detail the data conversion/migration process with roles and responsibilities clearly defined | Mandatory | |||
| 23.3 | 23 | 3 | Non-functional | Data Conversion / Migration | System shall allow data migration/import of information in the existing system to the new system for continuity and ease of record searching | Mandatory | |||
| 23.4 | 23 | 4 | Non-functional | Data Conversion / Migration | Vendor shall provide detailed plans for data verification post-migration to ensure data integrity | Mandatory | |||
| 24.0 | 24 | 0 | Software | ||||||
| 24.1 | 24 | 1 | Non-functional | Software | Vendor shall provide a diagram of the system architecture of the proposed software | Nice to have | |||
| 25.0 | 25 | 0 | Network | ||||||
| 25.1 | 25 | 1 | Non-functional | Network | Vendor shall provide configuration document, logical diagram for connectivity, and network diagram for any network requirements | Nice to have | |||
| 26.0 | 26 | 0 | Backup, Storage, Cloud Computing | ||||||
| 26.1 | 26 | 1 | Non-functional | Backup, Storage, Cloud Computing | Real-time or hourly backups | Mandatory | |||
| 26.2 | 26 | 2 | Non-functional | Backup, Storage, Cloud Computing | Data shall be housed in the U.S. and/or Canada | Mandatory | |||
| 26.3 | 26 | 3 | Non-functional | Backup, Storage, Cloud Computing | Vendor shall provide a list of their data centers | ||||
| 27.0 | 27 | 0 | Privacy Compliance | ||||||
| 27.1 | 27 | 1 | Non-functional | Privacy Compliance | The vendor shall complete Vendor Information Security Assessment (VISA) form, and acknowledge and agree to comply with the additional security compliance requirements resulting from the VISA | Mandatory | Only needed if vendor is selected | ||
| 27.2 | 27 | 2 | Non-functional | Privacy Compliance | The Vendor shall formally acknowledge and agree to comply with the City’s Information and Privacy Policy | Mandatory | Only needed if vendor is selected | ||
| 27.3 | 27 | 3 | Non-functional | Privacy Compliance | Vendor shall formally acknowledge and agree to comply with the City’s Saas Security and Privacy Terms and Conditions prior to entering into the contract | Mandatory | |||
| 27.4 | 27 | 4 | Non-functional | Privacy Compliance | Vendor shall agree to provide applicable compliance documents as required by the product/solution being purchased | Mandatory | |||
| 28.0 | 28 | 0 | Security Compliance | ||||||
| 28.1 | 28 | 1 | Non-functional | Security Compliance | Alignment with either ISO 27001 (Information Secuirty Management Systems) or NIST 800-53 (Security and Privacy Controls for Information Systems) | Mandatory | Only needed if vendor is selected | ||
| 28.2 | 28 | 2 | Non-functional | Security Compliance | Data encryption at rest and in transit using industry standards | Mandatory | |||
| 28.3 | 28 | 3 | Non-functional | Security Compliance | Alignment with PCI for payment processing compliance | Mandatory | |||
| 29.0 | 29 | 0 | Auditability | ||||||
| 29.1 | 29 | 1 | Non-functional | Auditability | System logs all user & system actions and events (who, what, when) required by auditors, and by IT and business and the length of time that the records must be kept | Mandatory | |||
| 30.0 | 30 | 0 | Maintainability and Scalability | ||||||
| 30.1 | 30 | 1 | Non-functional | Maintainability and Scalability | System shall allow City to be able to configure the system with appropriate access privileges | Mandatory | |||
| 30.2 | 30 | 2 | Non-functional | Maintainability and Scalability | The vendor shall have the appropriate team that will be available to fully maintain and manage system upgrades and software patches to repair defects | Mandatory | |||
| 30.3 | 30 | 3 | Non-functional | Maintainability and Scalability | The vendor shall have the appropriate team or third party vendor to fully maintain interfaces and/or enhancements | Nice to have | |||
| 30.4 | 30 | 4 | Non-functional | Maintainability and Scalability | System shall be designed to handle scalable operations. It shall support an increase in user load and data volume, ensuring consistently optimal performance without degradation of service or user experience | Mandatory | |||
| 31.0 | 31 | 0 | Supportability | ||||||
| 31.1 | 31 | 1 | Non-functional | Supportability | After go live support: 60 days fire-fighting support after go live with documented problems tracking and status | Nice to have | |||
| 31.2 | 31 | 2 | Non-functional | Supportability | On-going vendor support: The vendor shall provide their different support options and its associated pricing | Mandatory | |||
| 31.3 | 31 | 3 | Non-functional | Supportability | Vendor shall provide an online discussion forum and self-helf knowledge base for its customers to connect and learn from other customers | Nice to have | |||
| 31.4 | 31 | 4 | Non-functional | Supportability | Vendor shall provide a support ticketing system for reporting issues | Mandatory | |||
| 31.5 | 31 | 5 | Non-functional | Supportability | Vendor shall provide support services during standard business hours in Pacific Standard Time (PST) | Mandatory | |||
| 31.6 | 31 | 6 | Non-functional | Supportability | Vendor shall provide comprehensive API documentation and developer portals, including usage guidelines, and examples, to facilitate ease of use and efficient implementation by third-party developers | Mandatory | |||
| 32.0 | 32 | 0 | Service Level Agreement (SLA) | ||||||
| 32.1 | 32 | 1 | Non-functional | Service Level Agreement (SLA) | SLA between the vendor and the City must be clearly defined using the vendor’s template. | Mandatory | |||
| 32.2 | 32 | 2 | Non-functional | Service Level Agreement (SLA) | SLA will be reviewed and re-negotiated when the contract is up for renewal | Mandatory | |||
| 33.0 | 33 | 0 | Open Data | ||||||
| 33.1 | 33 | 1 | Non-functional | Open Data | All system data should be exportable and machine readable to support open data environment. | Mandatory | |||
| 33.2 | 33 | 2 | Non-functional | Open Data | Exportable data shall include metadata (set of data that describes and gives information about other data) | Nice to have | |||
| 34.0 | 34 | 0 | Data Liberation | ||||||
| 34.1 | 34 | 1 | Non-functional | Data Liberation | The City will own the data under a hosting agreement | Mandatory | |||
| 34.2 | 34 | 2 | Non-functional | Data Liberation | The vendor shall provide a transition plan (e.g., in the event we discontinue the service) with roles and responsibilities clearly defined and associated costs if any. | Mandatory | |||
| 35.0 | 35 | 0 | Disaster Recovery and Business Continuity | ||||||
| 35.1 | 35 | 1 | Non-functional | Disaster Recovery and Business Continuity | Overview of Disaster Recovery and Business Continuity | Mandatory | |||
| 35.2 | 35 | 2 | Non-functional | Disaster Recovery and Business Continuity | Overview Recovery Time Objective / Recovery Point Objective | Mandatory | |||
| 36.0 | 36 | 0 | Device and Cross-Platform Compatibility | ||||||
| 36.1 | 36 | 1 | Non-functional | Device and Cross-Platform Compatibility | The system must support Windows 10 or later | Mandatory | |||
| 36.2 | 36 | 2 | Non-functional | Device and Cross-Platform Compatibility | The system must support cross-platform compatibility, including iOS, Android, and iPadOS through native apps or browser-based access. | Nice to have | |||
| 36.3 | 36 | 3 | Non-functional | Device and Cross-Platform Compatibility | The user interface must support responsive web design for usability across a range of devices and screen sizes, including tablets and smartphones. | Mandatory | |||
| 36.4 | 36 | 4 | Non-functional | Device and Cross-Platform Compatibility | The system shall support for seamless data synchronization across multiple devices and platforms, ensuring data consistency and integrity in real-time. | Mandatory | |||
| 37.0 | 37 | 0 | Accessibility | ||||||
| 37.1 | 37 | 1 | Non-functional | Accessibility | Vendor shall meet or exceed compliance with Web Content Accessibility Guidelines (WCAG) 2.1 AA to facilitate access for users with disabilities, ensuring the software is inclusive. | Mandatory |
https://paloalto.buildingeye.com/planning Response Options
| Requirements and Capabilities | |
| Vendor Response | Description |
| Y - Yes, functionality is available | Functionality is available (Yes) as a standard feature of the software. |
| R - Available through reporting | Functionality is available through reports generated using proposed Reporting tools. |
| C - Available through customization | Functionality is provided through a Customizations to the application, including creation of a new workflow or development of a custom interface, which may have an impact on future upgradability. |
| F - Available in a future release | Functionality is not available now, but will be available in a Future release of the software within one year. |
| N - Not available | Functionality is Not Available. |
| Requirement Priority Levels | |
| Mandatory | Minimum Functionality/Must Have |
| Nice to have | Enhanced Functionality/Future Growth |
File details come from the government source that posted it. Updated .