DPW_Parks_SE_Functional_Requirements_Matrix.xlsx
XLSX spreadsheet 63 KB Posted
- Solicitation number
- 2022-RFP-246
- Issued by
- Allegheny County, Pennsylvania
About this file
The document is a functional requirements matrix for a Facility/Recreational/Special Events Permitting & Scheduling System for the City of Pittsburgh, involving the Departments of Public Works, Parks and Recreation, and other city agencies. The project seeks a comprehensive software solution to replace existing outdated permitting systems, with requirements spanning multiple functional areas including special events management, recreation center memberships, facility rentals, and integrated payment processing. The solution must be web-based, mobile-capable, and provide robust features such as online applications, permit issuance, payment integration, reporting capabilities, and support for various city departments' specific needs.
The system requirements emphasize strict data security protocols, including 99.99% uptime, encryption at rest and in transit, compliance with CJIS security policies, and annual third-party security assessments. Key technical requirements include cloud-based hosting (preferably on Google Cloud Platform), compatibility with city payment systems, open API access, role-based access controls, and the ability to store data for a minimum of seven years. The solution must support multiple platforms, integrate with existing city applications, provide comprehensive reporting, and offer technical support during standard business hours. No specific budget or funding source is detailed in the document, but the requirements suggest a sophisticated, enterprise-level system tailored specifically to the City of Pittsburgh's complex permitting and scheduling needs.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Facility_Recreational_Special_Events_Permitting_&_Scheduling_System.pdf | ||
| Standard_SLA_with_Remedy.doc | DOC document |
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
Technical Requirements Final
| Requirement ID | Requirements | |
| (All of the items apply to any subcontractors that work on the solution. ) | System Capability | |
| (select from dropdown) | Comments: | |
| Outage and Breach Reporting: | ||
| 1.1 | Provide your outage notication communication | |
| 1.2 | Provides fast detection and root cause diagnosis | |
| 1.3 | The City of Pittsburgh (referred to as City) must be notified in writing within 24 hours of the earliest indication or report of a potential breach or unintended disclosure of Confidential Information (CI) or a System that supports CI. | |
| 1.4 | Response actions to incidents that might affect CI or Systems must be conducted quickly and with ample resources. Vendor will hire a professional third-party incident response team if in-house resources do not have sufficient skill or availability. The Vendor is expected to distribute all incident response evidence, reports, communications and related materials to security@pittsburghpa.gov. The format of incident reports will be agreed upon with the City in advance. | |
| 1.5 | City shall have the right to view all incident response evidence, reports, communications and related materials upon request. | |
| 1.6 | If requested by the City, or if required by law, the Vendor shall notify in writing all persons affected by the incident, at its own cost and expense. | |
| 1.7 | Vendors shall have a comprehensive secure development system in place consistent with industry standard best practices, including policies, training, audits, testing, emergency updates, proactive management, and regular updates to the secure development lifecycle System itself. | |
| 1.8 | Vendors will make updates available to the City in a timely fashion at no additional cost. | |
| 1.9 | The system can provide the ability to track and log system uptime and transaction response times in order to provide information for SLA monitoring | |
| 1.10 | Provides for predictive failures and issue alerting functions | |
| 1.11 | Ability to allow for notification of blackouts | |
| Data and Security: | ||
| 2.1 | All cloud-hosted data must remain in the continental United States. | |
| 2.2 | Ownership of all data remains with the City, at no additional cost. | |
| 2.3 | Data should be encrypted at rest and in transit. | |
| 2.4 | The City shall have the right to view all documentation containing the results of any security audits completed within the last twelve (12) months, including documentation regarding security practices and data classification. | |
| 2.5 | The Vendor shall use commercially reasonable efforts to secure and defend any System housing Confidential Information against third parties. | |
| 2.6 | Vendors that handle Confidential Information must respond to and resolve security-related bug reports, inquiries and incidents in a timely and professional manner. The Vendor must notify the City within 24 hours of when Vendor becomes aware of any such incident that poses a potential risk to City data. The Vendor shall send the notification to security@pittsburghpa.gov | |
| 2.7 | Must follow industry standard password requirements. (Passwords must be stored in non-reversible one-way cryptographic hash) | |
| 2.8 | Log all successful and failed authentication attempts, including date, time, IP address, and username. | |
| 2.9 | Offer a secure password reset feature, including verification of identity, email or text notification. | |
| 2.10 | Temporarily lock accounts with repeated failed login attempts and provide support to affected users. | |
| 2.11 | Ability to provide authentication via generally agreed upon SSO methodologies. | |
| 2.12 | Vendors managing City-owned CI must engage an independent third party annually to assess the practical security of Vendor's Systems. These reviews must include penetration tests from the perspective of an external attacker and an internal user with common privileges. The penetration tests must include all Systems exposed to the internet and any Systems, internal or external, that Handle Confidential Information. Such annual assessment shall be at Vendor’s sole expense. | |
| 2.13 | Audit logs must be implemented for all Systems including those that handle CI. All attempted violations of System security must generate an audit log. Audit logs must be secured against unauthorized access or modification. Electronic logs required | |
| 2.14 | In the event of adverse findings through a City or Vendor audit, the Vendor shall cooperate with the City in remediating any risks to CI, including complying with request to temporarily taking the system offline or otherwise limiting access to the system, and any other follow up actions reasonably necessary to secure the CI. | |
| 2.15 | For the life of the contract, all data should be retained and available upon request from the City, available via API calls. | |
| 2.16 | All metadata, logs, notifications of system outages, etc. should also be retained for the life of the contract. | |
| 2.17 | Vendor Systems that Handle Confidential Information shall be available and fully functional 24x7x365 with 99.99% uptime, unless otherwise agreed upon in writing with the City. Vendor shall make plans for colocation, backups and any other Systems necessary to ensure continuity. | |
| 2.18 | Vendor must notify and obtain agreement from the City for any planned interruptions in service, with the exception of emergency security updates. Vendor must notify the City immediately of any unintended service interruption. | |
| 2.19 | RFP responses should include a plan for content availability in the event of the need to migrate to a different platform. Remittance of content directly to the City of Pittsburgh is acceptable. | |
| 2.20 | Include online Help | |
| 2.21 | Comprehensive Security |
o Local certificates, trusted certificates, and 128-bit SSL
| 2.22 | System should be able to provide an unlimited number of different security groups that can be defined, each with their own security settings and group names that are appropriate. |
| 2.23 | ISO/IEC 27001 Certification or in pursiut of audit before working with the City |
| 2.24 | Storage needs to be capable of compliance with CJIS Security Policy storage requirements: https://www.fbi.gov/services/cjis/cjis-security-policy-resource-center |
| Network: | |
| 3.1 | The solution must adhere to latest best network industry practices. |
| 3.2 | The solution must assure that the integrity of the City's network is sustained by the implementation and utilization of modern firewall, VPN and other remote access technologies. |
| 3.3 | The soluton must provide network authentication and system user events logging. |
| 3.4 | The solution must assure that there will be no degradation in performance of City's network due to their system or design. |
| 3.5 | Proposers must include a list of web browsers and devices their system does/does not support |
| Solution Infrastructure: | |
| 4.1 | Solutions are preferred to be cloud based solutions hosted with the provider. If solution needs to be customer hosted enviroment, Google Cloud Platform is preferred. |
| 4.2 | Respondent must detail all additional software licenses that would be required to utilize the product/solution. |
| 4.3 | Provider solution must not incur additional software licensing expense. Provider solution must be a complete package. Solutions utilizing industry standard component applications such as MS SQL are preferred . |
| 4.4 | If and when a City owned software license for a component in the solution stack is viable for utilization to avoid additional software licensing expense, it is to be utilized. |
| 4.5 | If the suggested solution is to be implemented on the City Infrastructure, requirements for component resources from a virtualized hardware perspective are required. vCPU, Memory, Storage per server with an overall summary. |
| Data and Reporting: | |
| 5.1 | When geospatial information is needed, the Solution should have the ability to use City GIS layers hosted on ArcGIS online to create geocoding for locations and administrative geographies provided by the City |
| 5.2 | The system should allow for exporting of data through an open, REST API to the City's data ingestion system or the Western Pennsylvania Regional Data Center, as needed. |
| 5.3 | Vendor shall provide data dictionary for database fields, field types, number of characters, value ranges, relationship diagram(s) (database map) of the data model, and key fields used in relationships with database tables. |
| 5.4 | The API provided by the system should include documentation that contains: Sample requests, headers and other relevant metadata, Clear, comprehensive descriptions of the data represented in the API, such as its output format (e.g., JSON or CSV), understandable by someone with a basic to intermediate familiarity with the system, Generated code snippets in some of the most popular programming languages (e.g., Python). API documentation should include details of specific encodings, documentation, data types, requests, and objects for the API. |
| 5.5 | Supports a dashboard with a login |
dependent views
| 5.6 | Ability to provide trend analysis |
| 5.7 | Real-time Reporting |
o At least 150 configurable reports, real-time, and historical graphs
| 5.8 | City must have full ownership and free access to data captured by the System, both during and after the contract period |
| 5.9 | Full API Access - Access to our data through the use of an API must be provided. |
| 5.10 | A general site user must have the ability to embed third party code (ex. Google Calendar) |
| 5.11 | Geospatial data must be compatible with ESRI systems and common geospatial data storage formats (.geojson, .dbf, .shp) |
| Miscellaneous: | |
| 6.1 | Companies from outside the United States are welcome to apply, provided they meet the standards as described above. |
| 6.2 | Remote meetings may be acceptable, with prior arrangement from the City. |
| 6.3 | The City's preference is that Adobe Flash not be part of this solution. |
| 6.4 | Role-based Management |
o Access network maps, configuration, alerts, notifications, reporting, and management console
| 6.5 | The system can accommodate separate instances of databases for testing, training, and quality assurance |
| 6.6 | The vendor shall provide customer service support during the City of Pittsburgh's normal business hours. |
| 6.7 | The vendor shall provide "As-Built" documentation to the City of Pittsburgh representing the state of the application service at the time of Go-Live. |
| Project-Specific Technical Requirements (Mandatory): | |
| 7.1 | Solution to run on multiple Windows platforms |
| 7.2 | Ability to support remote administration |
| 7.3 | Ability to export reports in common formats (PDF, Word, Excel) |
| 7.4 | Solution shall have built-in backup and restore capability |
| 7.5 | If solution hosts or utilized a source of data, solution must have built-in database maintenance and reporting tools |
| 7.6 | Vendor shall include a description of the system’s basic architecture |
| 7.7 | Vendor shall describe how the system handles multiple users, data concurrency control, record locking, and conflict resolutions |
| 7.8 | Vendor shall describe the hosting models (customer enviroment or vender enviroment) |
| 7.9 | Vendor shall describe if the solution servers can be virtualized (and if so, describe the system) |
| 7.10 | Vendor shall describe hardware requirements or recommendations |
| 7.11 | If applicable, describe how the solution can perform database maintenance, including, but not limited to, backup and upgrades without requiring system downtime |
| 7.12 | If applicable, describe the solutions ability to auto-discover targets on the network |
| 7.13 | If applicable, describe the solutions ability to monitor an application and its performance with agentless configurations where possible. |
| 7.14 | If applicable, describe the solutions ability to monitor user response time and throughput by location or other logical grouping. |
| 7.15 | If applicable, describe the solutions ability to drill down into the full |
technical details on how the server and the browser interact with one another.
| 7.16 | If applicable, describe the solutions ability to assemble an e-mail, with one click, that includes a complete user session with replay to provide additional information when triaging an incident. |
| 7.17 | Must support alerting and notifications by email, SMS, pager message, and HTTP |
request
| 7.18 | Vender must provide a visual of the solutions network Mapping, Network topology, subnets, devices, applications, and systems. |
| 7.19 | If applicable, solution should have configurable monitoring that identifys performance, passive, active, real-time, custom (scripted), monitoring templates, and bulk changes |
| 7.20 | If applicable, solution should have have predictive Alerting that is customizable and identifies up, down, and threshold (min/max), maintenance mode, device dependency, and escalation. |
| 7.21 | If applicable, solution must support, SNMP (supports SNMP V1, V2c and V3), WMI (Windows Management Instrumentation), HTTP based services, TCP and UDP based services including PING, Port, SMTP, POP3, FTP |
| Integration or API Requirements (Project-Specific - I&P review this section for relevance to each project/solitication ) | |
| 8.1 | Ability to support two-way communication with Microsoft Outlook |
| 8.2 | Ability to integrate with payroll systems to include, but not limited to Ceridien TimePro version |
| 8.3 | Vendor shall describe if the system have built-in integration with other systems |
| 8.4 | Vendor shall describe if the system can import date from various formats (XML, CSV, TXT). |
| 8.5 | The vendor shall INTERACT with City specific applications (for example APRS, Firehouse, CYA, etc) |
| 8.6 | Solution allows for reading/writing of map services specifically created and published via ArcGIS for Server environment |
| 8.7 | Integrates with existing monitoring tools |
Special Events
| Requirement ID | Requirements | ||
| (All of the items apply to any subcontractors that work on the solution. ) | System Capability | ||
| (select from dropdown) | Comments: | ||
| Capabilites and Features | |||
| CAP001 | Web based & mobile capable | System should function properly on all major internet browsers and mobile platforms | |
| CAP002 | User-friendly & intuitive | ||
| CAP003 | Ability to collect online event & film applications | ||
| CAP004 | Fully customizable by client, from questions to page design | questions, text, logos, etc should be controllable on client end | |
| CAP005 | Ability to allow permission level access to administrators or key stakeholders | edit access, read-only, etc | |
| CAP006 | Ability to download & upload any required and/or supporting documents | ||
| CAP007 | Storage & Management of uploaded supporting documents | ||
| CAP008 | Ability to allow online payment through internal or synced system | must be able to integrate with City's payment processing system (Jetpay) | |
| CAP009 | Ability to create and send invoices | ||
| CAP010 | Ability to track status of each application both internally and user facing | ||
| CAP011 | Ability to track process updates from Coordinators & Administrators | ||
| CAP012 | Ability to issue approved permits via email (PDF format) | ||
| CAP013 | Ability to allow customizable information dissemination | should be able to share information from the system with internal stakeholders as needed | |
| CAP014 | Email Integration | should be able to send messages to applicants and internal stakeholders within the system | |
| CAP015 | Report Generation (see Reporting section below) | ||
| CAP016 | Ability assign/reassign Coordinators / Reviewers | must be able to assign applications to applications to different staff for review | |
| CAP017 | Ability to allow for selection of permit type by user / multiple permit types | ||
| CAP018 | Ability for user to create profile for login/logout; admin capability to reset passwords | ||
| CAP019 | Ability to allow users to save application progress and return later to complete | ||
| CAP020 | Online dashboard for applicants to track the status of their application(s) | ||
| CAP021 | Ability for Administrators to create email groups for quick information dissemination through the system | ||
| CAP022 | System-based calendar to track dates and times of requested event & film activity / check for date conflicts | ||
| CAP023 | Public-facing event calendar with control on what data presents on calendar | ||
| CAP024 | Ability to allow users to create basic event maps / integrate with similar | ||
| CAP025 | Ability to have users agree to “terms & conditions” before application submission | ||
| CAP026 | Ability to have permits be editable (i.e. additional terms or conditions) prior to issuance | ||
| CAP027 | Ability for applicants to enter multi-day or recurring events with start/end times for each day | ||
| CAP028 | Ability to archive completed applications for future reference | ||
| CAP029 | Ability to restrict available dates based on permit policy (i.e. cannot apply under 14 business days before selected event date) | ||
| Accuracy | |||
| ACC001 | System is expected to be free of major typographical errors and displays uploaded and custom question / requirements correctly (i.e. fee schedules, etc). | ||
| ACC002 | System should be free of glitches & errors; data should be trustworthy and accurate | ||
| Performance and Reliability | |||
| PER001 | System must be reliable and not have extended down time (> 5% of weekly business hours). System maintenance should not be performed during City of Pittsburgh business hours (8am – 5pm Monday through Friday). | ||
| PER002 | System Maintance should be pre-scheduled with at least 48 hours notice to the City of Pittsburgh to allow for proper notification to constituents. | ||
| Security | |||
| SEC001 | System must be able to allow permission/role based access to different administrators or interested parties. | ||
| Support | |||
| SUP001 | Awardee should be able to provide technical support in the form of a dedicated customer service representative (and alternate) who is available during City of Pittsburgh business hours and can respond via phone or email within a short time to requests for support. | ||
| SUP002 | Awardee should be able to provide technical support to the general population / City of Pittsburgh applicants who may need assistance beyond the capability of City staff | ||
| Scalability and Capacity | |||
| SCA001 | System should be able to store application and permit data for the minimum of seven (7) years per public record law. | ||
| SCA002 | System must not limit the number or size of applications submitted in a calendar year. | ||
| Interfaces | |||
| INT001 | System must be compatible with City of Pittsburgh online credit card payment systems and external invoice generation systems, as necessary. | ||
| INT002 | System must provide full accessibility to data; must work with City’s cloud provider. | ||
| INT003 | System must be able to sustain a two-way interface with City of Pittsburgh’s other permitting applications (Computronix). | ||
| INT004 | System must provide open API | ||
| Reporting Requirements | |||
| RPT001 | System must be capable of generating downloadable reports based on applications, such as quantity issued by type, by location, on a specific date, per organizer, by reviewer, etc. as well as financial data such as debts owed, debts collected, etc. |
Citiparks
| Requirement ID | Requirements | ||
| (All of the items apply to any subcontractors that work on the solution. ) | System Capability | ||
| (select from dropdown) | Comments: | ||
| Capabilites and Features | |||
| CAP001 | Manage Rec Center Memberships | ||
| CAP002 | Track Rec Center Memberships with scan cards (or suitable substitute) when coming/going from building | ||
| CAP003 | Track Rec Center Memberships for kids (FREE) admission at pools--use upon each entry so we can see clear #'s | ||
| CAP004 | Demographic Data Collection and reporting | including but not limited to Name, age, e-mail, phone, address, neighborhood, rec/ethnic background |
Allow for inputting our own paramenters for running reports--to be center specific, neighborhood, or zip code
| CAP005 | Ability to book appointments for certain areas in the center--fitness room, public facing computer, open gym forums, etc | Should we need to limit attendance--as learned from pandemic |
| CAP006 | Ability for public to register/singup and pay for classes, programs, camp, swim lessons, etc | Including ALL Locations and all CitiParks Program arms |
| CAP007 | e-mail distributions for registered participants by program type--confirmations, reminders, etc. (Automated or manual) | |
| CAP008 | Ticketing/Admissions--Rink, Pool Passes, Tennis Clincs & Bubble standing court times | |
| CAP009 | Permitting of Tennis and Pickleball Courts--produce permit, process payment | |
| CAP010 | HAL & REC Center Permitting--Automated form/create booking, produce permit, process payment | |
| CAP011 | Rink--Banquet Room, Party Room & Private Ice Time--create booking, produce permit, process payment | |
| CAP012 | Roving Art Cart-Large Group Registration | Currently done through RedTail-needs approval from CEP |
| CAP013 | Ability to download e-mail/names by specific parameters to market new programs | |
| CAP014 | CitiSports--facilitate team sign-ups/registrations/game scheduling--for all sports, baseball, softball, basketball, futsal | |
| CAP015 | Web based & mobile capabilities | |
| CAP016 | User friendly (both internally & externally) | |
| CAP017 | Permissions based access levels--User, Employee, Administration & key stakeholders | |
| CAP018 | Ability for user to create profile for login/logout; admin capability to reset passwords | |
| CAP019 | Must have seamless connection to City's Payment processor | |
| CAP020 | Ability to easily update customer records--both internally and externally | |
| CAP021 | ||
| CAP022 | ||
| CAP023 | ||
| CAP024 | ||
| CAP025 | ||
| CAP026 | ||
| CAP027 | ||
| CAP028 | ||
| CAP029 | ||
| Accuracy | ||
| ACC001 | System should be able to monitor scheduled counts/dates to ensure no double or over bookings | |
| ACC002 | System should be free of glitches & errors; data should be trustworthy and accurate | |
| Performance and Reliability | ||
| PER001 | System must be reliable and not have extended down time. | |
| Security | ||
| SEC001 | System must be able to allow permission/role based access to different administrators or interested parties. | |
| Support | ||
| SUP001 | Awardee should be able to provide technical support in the form of a dedicated customer service representative (and alternate) who is available during City of Pittsburgh business hours and can respond via phone or email within a short time to requests for support. | |
| SUP002 | ||
| Scalability and Capacity | ||
| SCA001 | System should be able to store data for the minimum of seven (7) years per public record law. | |
| SCA002 | System must not limit the number of records submitted in a calendar year. | |
| Interfaces | ||
| INT001 | System must be compatible with City of Pittsburgh online credit card payment systems and external invoice generation systems, as necessary. | |
| INT002 | System must provide full accessibility to data; must work with City’s cloud provider. | |
| INT003 | System must provide open API | |
| INT004 | ||
| Reporting Requirements | ||
| RPT001 | System must be able to provide a variety of reports on all data collected | |
| RPT002 | System must be able to track financial data--to ensure all fees are collected properly |
DPW
| Requirement ID | Requirements | |||
| (All of the items apply to any subcontractors that work on the solution. ) | System Capability | |||
| (select from dropdown) | Comments: | |||
| Capabilites and Features | ||||
| CAP001 | Manage Facility Rentals | |||
| CAP002 | Ability for customers to reserve or request facilities including, but not limited to park shelters, overlooks, walled garden, and other spaces via online platform. | |||
| CAP003 | Ability for cusomters to request fields, dek hockey, basketball, and bocce courts via online platform. | |||
| CAP004 | Ability for customers to easily check facility availability via calendar view online, with control on what data shows on public facing calendar. | Current software is hard-coded when customer checks availability. If customer selects date that is already booked, the words "CONFLICT" in red appears. Need to be able to customize hard-coded wording. | ||
| CAP005 | Ability for customers to view a map, photos, and dimensions of the facility online. | |||
| CAP006 | Demographic Data Collection and reporting (see below) | Including, but not limited to reporting information related to specific facility rentals (i.e. specific permit use type, customer demographics, etc.) | ||
| CAP007 | Ability for more seamless a way for customers to receive a copy of their permit via online portal. | RecPro currently has a way for customers to download a copy of their permit, but it requires multiple steps and is confusing for the customer to access. Would be useful for custmers to click a "send permit" link and easily receive a copy of the permit automatically via email. | ||
| CAP008 | Ability easily scan and detect for key words in permit types for facility rentals that may need additional permitting (i.e. Special Events Permits, etc.) | Software could help detect for permits that were issued online which would require Special Events Permits (i.e. pop-up shops, vending, permits that extend beyond space included with DPW permit) | ||
| CAP009 | Ability to download and add attachments to a facility permit (rosters, schedules, COIs, etc.) | DPW currently sets up permits and keeps rosters, schedules, and COIs on file, but need ability to add them all into 1 program). | ||
| CAP010 | Web-based and mobile capabilities (see below for specifics). | |||
| CAP011 | Must have seamless connection to City's payment processor. | |||
| CAP012 | Ability to easily update customer records, both internally and externally. | Requesting an easier way to internally enable customer accounts, or provide a secure way for customers to enable their own account. We manually enable their web account if/when needed. Most common issue we see is customer cannot reset their own password until they have their account enabled by us. | ||
| CAP013 | Ability to create permits that are more customizable tailored to specific to new/specific open park spaces (general permits) when needed. | General permits are permits that do not require additional City services, but would take place at a location not at an already created DPW facility. System needs to have capacity and ability to allow for creating new spaces for these general permits. These types of permits are typically for a variety of open spaces that aren't classified as a park shelter, ballfield, and do not quialify as a Special Event. | ||
| CAP014 | Ability to add a "How To" video tutorial for customers to follow instructions on how to reserve a facility. | |||
| CAP015 | Capacity to "customize" facility location addresses, if needed. | When you create a "facility" (park location) in RecPro and add a "room" it only allows you to list one address per facility. The main address is listed on the permit for the entire park, which makes it confusing for customers. | This can make the address location confusing for customers. Working on a short-term "fix" if possible. Parks such as Schenley Park that have numerous facilities only have the main park address listed, rather than being able to list one address per facility. | |
| CAP016 | Ability for DPW to efficiently modify existing permits (including adding or removing dates) without errors or unknown "conflicts." | Currently taking many extra unecessary steps to cancel or change a permit. The current software often does not remove all dates selected to cancel, creating extra work and revisions. | ||
| CAP017 | User Friendly (both internally and externally) | |||
| CAP018 | Provide options for residents that do not have access to a computer to reserve facilities | |||
| CAP019 | Provide options for residents that do not have a credit card, ie Paypal, Venmo, Zelle, EFT | |||
| CAP020 | ||||
| CAP021 | ||||
| CAP022 | ||||
| CAP023 | ||||
| CAP024 | ||||
| CAP025 | ||||
| CAP026 | ||||
| CAP027 | ||||
| CAP028 | ||||
| CAP029 | ||||
| Accuracy | ||||
| ACC001 | System should be able to monitor all facility booking / dates to ensure no double or over-booking. | |||
| ACC002 | System should be free of glitches and errors; data should be trustworthy and accurate. | |||
| Performance and Reliability | ||||
| PER001 | System must be reliable and not have extrended downtime. | |||
| Security | ||||
| SEC001 | System must be able to allow permission/role based access to different administrators or interested parties. | |||
| Support | ||||
| SUP001 | Awardee should be able to provide technical support in the form of a dedicated customer service representative (and alternate) who is available during City of Pittsburgh business hours and can respond via phone or email within a short time to requests for support. | |||
| SUP002 | The software solution must be able to provide tutorials/instructions on how to use the system that the City can share with our public. | The City must be able to provide easy equal access/login for all customers to have opportunity to rent a park facility, regardless of internet speed/access. | ||
| SUP003 | The software solution must be able to accept an application from the Admin side on behalf of the applicant that may not have a computer or internet . | The City must be able to provide easy equal access/login for all customers to have opportunity to rent a park facility, regardless of internet speed/access. | ||
| Scalability and Capacity | ||||
| SCA001 | System should be able to store application and permit data for the minimum of seven (7) years per public record law. | |||
| SCA002 | System must not limit the number of permits drafted in a calendar year or given day. | Current system often crashes during times of high volume permitting, especially during peak field and shelter permitting months. | ||
| Interfaces | ||||
| INT001 | System must be compatible with City of Pittsburgh online credit card payment systems and external invoice generation systems, as necessary. | |||
| INT002 | System must provide full accessibility to data; must work with City’s cloud provider. | |||
| INT003 | System must provide open API. | |||
| INT004 | System must be consistent when customer is using software on smartphone vs. on a desktop | DPW noticed drop-down menu at registerparks.pittsburghpa.gov on front page of left side of screen does not show up on mobile devices; this is key to help direct customers to other departments. | ||
| Reporting Requirements | ||||
| RPT001 | System must be capable of generating a variety of reports based on facility permits issued, including but not limited to ARAD revenue, facility demographic information, facility schedules for parks divisions, etc. | System should show many times a given facility is permitted in a week, month, year, etc. This information helps DPW record data for facility usage, which assists DPW with maintenance and understanding future budget needs. | ||
| RPT002 | System must be able to track financial data, overdue balances, etc. |
Index
| Core Capability |
| Configurable by Vendor |
| Configurable by City Staff |
| Requires Customization |
| Provided in Conjunction with a 3rd Party |
| Not Applicable |
Data Validation
| Core Capability |
| Configurable by Vendor |
| Configurable by City Staff |
| Requires Customization |
| Not Applicable |
File details come from the government source that posted it. Updated .