Appendix_D_Requirements_Template_Grants_Solution_(1).xlsx

XLSX spreadsheet 50 KB Posted

Attached to
Sub-recipient Grants Solution
Solicitation number
2022-RFP-216
Issued by
Allegheny County, Philadelphia City, Pennsylvania

About this file

This document is a technical requirements template for a grants management solution from the City of Pittsburgh's Office of Management and Budget, seeking software to manage reimbursement processes for over 150 sub-recipient federal grants annually. The comprehensive technical requirements outline detailed specifications for a cloud-based or virtualized system that must provide robust data security, reporting capabilities, integration features, and comprehensive functional requirements across multiple domains including outage reporting, data management, network security, server infrastructure, and integration capabilities.

The solution requires specific technical capabilities such as 99.99% system uptime, data encryption, secure authentication methods, API accessibility, geospatial compatibility, and the ability to support multiple users and platforms. Pricing considerations include application costs, training expenses, implementation fees, and five-year total cost of ownership, with preferences for cloud-based solutions hosted on Google Cloud Platform or utilizing existing City software licenses. The system must integrate with existing enterprise resource planning (ERP) systems like JDE, support digital document transmission, enable multi-stage invoice approvals, and provide customizable reporting and notification features for different user roles within the City's Office of Management and Budget.

View the file

Other files

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

Requirement IDRequirements
(All of the items apply to any subcontractors that work on the solution. )System Capability
(select from dropdown)Comments:
Outage and Breach Reporting:
1.1Provide your outage notication communication
1.2Provides fast detection and root cause diagnosis
1.3The 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.4Response 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.5City shall have the right to view all incident response evidence, reports, communications and related materials upon request.
1.6If 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.7Vendors 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.8Vendors will make updates available to the City in a timely fashion at no additional cost.
1.9The system can provide the ability to track and log system uptime and transaction response times in order to provide information for SLA monitoring
1.10Provides for predictive failures and issue alerting functions
1.11Ability to allow for notification of blackouts
Data and Security:
2.1All cloud-hosted data must remain in the continental United States.
2.2Ownership of all data remains with the City, at no additional cost.
2.3Data should be encrypted at rest and in transit.
2.4The 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.5The Vendor shall use commercially reasonable efforts to secure and defend any System housing Confidential Information against third parties.
2.6Vendors 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.7Must follow industry standard password requirements. (Passwords must be stored in non-reversible one-way cryptographic hash)
2.8Log all successful and failed authentication attempts, including date, time, IP address, and username.
2.9Offer a secure password reset feature, including verification of identity, email or text notification.
2.10Temporarily lock accounts with repeated failed login attempts and provide support to affected users.
2.11Ability to provide authentication via generally agreed upon SSO methodologies.
2.12Vendors 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.13Audit 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.14In 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.15For the life of the contract, all data should be retained and available upon request from the City, available via API calls.
2.16All metadata, logs, notifications of system outages, etc. should also be retained for the life of the contract.
2.17Vendor 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.18Vendor 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.19RFP 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.20Include online Help
2.21Comprehensive Security

o Local certificates, trusted certificates, and 128-bit SSL

2.22System 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.23ISO/IEC 27001 Certification or in pursiut of audit before working with the City
2.24Storage 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.1The solution must adhere to latest best network industry practices.
3.2The 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.3The soluton must provide network authentication and system user events logging.
3.4The solution must assure that there will be no degradation in performance of City's network due to their system or design.
3.5Proposers must include a list of web browsers and devices their system does/does not support
Server and Virtualization:
4.1Solutions 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.2Respondent must detail all additional software licenses that would be required to utilize the product/solution.
4.3Provider 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.4If 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.5If 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.
4.6
Data and Reporting:
5.1When 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.2The 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.3Vendor 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.4The 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.5Supports a dashboard with a login

dependent views

5.6Ability to provide trend analysis
5.7Real-time Reporting

o At least 150 configurable reports, real-time, and historical graphs

5.8City must have full ownership and free access to data captured by the System, both during and after the contract period
5.9Full API Access - Access to our data through the use of an API must be provided.
5.10A general site user must have the ability to embed third party code (ex. Google Calendar)
5.11Geospatial data must be compatible with ESRI systems and common geospatial data storage formats (.geojson, .dbf, .shp)
Miscellaneous:
6.1Companies from outside the United States are welcome to apply, provided they meet the standards as described above.
6.2Remote meetings may be acceptable, with prior arrangement from the City.
6.3The City's preference is that Adobe Flash not be part of this solution.
6.4Role-based Management

o Access network maps, configuration, alerts, notifications, reporting, and management console

6.5The system can accommodate separate instances of databases for testing, training, and quality assurance
6.6The vendor shall provide customer service support during the City of Pittsburgh's normal business hours.
6.7The 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.1Solution to run on multiple Windows platforms
7.2Ability to support remote administration
7.3Ability to export reports in common formats (PDF, Word, Excel)
7.4Solution shall have built-in backup and restore capability
7.5If solution hosts or utilized a source of data, solution must have built-in database maintenance and reporting tools
7.6Vendor shall include a description of the system’s basic architecture
7.7Vendor shall describe how the system handles multiple users, data concurrency control, record locking, and conflict resolutions
7.8Vendor shall describe the hosting models (customer enviroment or vender enviroment)
7.9Vendor shall describe if the solution servers can be virtualized (and if so, describe the system)
7.10Vendor shall describe hardware requirements or recommendations
7.11If applicable, describe how the solution can perform database maintenance, including, but not limited to, backup and upgrades without requiring system downtime
7.12If applicable, describe the solutions ability to auto-discover targets on the network
7.13If applicable, describe the solutions ability to monitor an application and its performance with agentless configurations where possible.
7.14If applicable, describe the solutions ability to monitor user response time and throughput by location or other logical grouping.
7.15If 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.16If 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.17Must support alerting and notifications by email, SMS, pager message, and HTTP

request

7.18Vender must provide a visual of the solutions network Mapping, Network topology, subnets, devices, applications, and systems.
7.19If applicable, solution should have configurable monitoring that identifys performance, passive, active, real-time, custom (scripted), monitoring templates, and bulk changes
7.20If 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.21If 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
7.22
7.23
Integration or API Requirements (Project-Specific - I&P review this section for relevance to each project/solitication )
8.1Ability to support two-way communication with Microsoft Outlook
8.2Ability to integrate with payroll systems to include, but not limited to Ceridien TimePro version
8.3Vendor shall describe if the system have built-in integration with other systems
8.4Vendor shall describe if the system can import date from various formats (XML, CSV, TXT).
8.5The vendor shall INTERACT with City specific applications (for example APRS, Firehouse, CYA, etc)
8.6Solution allows for reading/writing of map services specifically created and published via ArcGIS for Server environment
8.7Integrates with existing monitoring tools
8.8

Functional Requirements

Requirement IDRequirements
(All of the items apply to any subcontractors that work on the solution. )System Capability
(select from dropdown)Internal Comments
General Features (Required)Must Have, Nice to Have, Need to HaveComments:
1General Requirements for Overall Process & Accessability
1.1Ability to enter a unique contract ID that is generated by the Controller's OfficeMust Have
1.2Ability to assign multiple contracts to one vendor.Must Have
1.3Ability for each contract to have multiple invoicesMust Have
1.4Ability for each vendor to transmit documents digitally and have them stored in the system.Must Have
1.5Availability of necessary storage space for the amount of documents we receive.Must Have
1.6Ability to document payment for invoice or requisition in the system ie enter check number, GL number and amount.Must Have
1.7Ability to reflect accounting records or from our current ERP vendor, JDE and with any other ERP systems if replaced.Must Have
1.8Integration between vendor solution and our currentt ERP vendor, JDE and any other ERP systems if replaced, specific to the assigned contract numberMust Have
1.9Ability to approve discreet components of an invoice (line by line submissions)Must Have
1.1Ability to approve/disallow an expense with an additonal comment for each line itemMust Have
1.11Ability, once a reimbursement request is submitted, to go through a series of approvalsMust Have
1.12Ability to pre-load all categories and applicable sub-categoriesMust Have
1.13Ability to resubmit once something has been rejected.Must Have
1.14Ability to create reports that are not pre-cannedMust Have
1.15Ability to assign multiple users on the vendor (group) and City side.Must Have
1.16
1.17
1.18
2Notifications
2.1Ability to track the date of any issue sent back to the vendor and resubmitted to the City.Must Have
2.2Ability for the system to alert staff that this specific funding source has not been drawn down over the past 90 days. (ie As it concerns CDBG funding, a particular subrecipient has X amount of funds outstanding and is now receiving X amount of new fund)s.Must Have
2.3Ability for system to send alerts (internal as well as external). (Example external alerts to Groups to let them know their invoice is processed and they will receive the check in 5 days. Internal alert example could be Fiscal Coordinator has prepared the DI, Fiscal Manager to approve then alert to Department Head and Program coordinator to sign after Fiscal Manager approves.)Must Have
2.4Ability for system to give a list of task as we log in every morning. (Task for Fiscal coordinator could be: Prepare invoice for Inv# received on Date, 2nd task could be – check if payment made by controller’s office for Batch # .)

(Task for Program Coordinators could be : Follow up with Group for missing documents, Update Accomplishments for Contract #... etc.)

Must Have
3Reporting & Dashboards
3.1Ability to setup alerts and reporting for staff related to turn around times on invoice approval and invoices that haven't been reviewed.Must Have
3.2Availability of a dashboard view of all open items for each staff member's assignmentsMust Have
3.3Availability for a vendor to see their own information but not any other vendor's info.Must Have
3.4Ability for staff member from Office of Management & Budget (OMB) to electronically transmit approved invoices to the Controller's OfficeMust Have
3.5Ability for multiple staff members to approve an invoice via a workflow ie the OMB Financial Planner can Approve the Entire Request and advance it to the OMB Manager. (Please see attached flow chart in Appendix)Must Have
3.6The ability to upload templated documents during the electronic submission to the Controller's OfficeMust Have
3.7Ability for OMB supervisor to assign a contract to a OMB staff memberMust Have
3.8Ability to assign permissions based on staff member's job titleMust Have
3.9
3.1
3.11
3.12
3.13
3.14
3.15
3.16
3.17
4
4.1
4.1.1
4.1.2
4.1.3
4.1.4
4.2
4.3
4.4
4.5
4.6
4.6.1
4.6.2
4.6.3
4.6.4
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.2
4.21
5
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.1
6
6.1
6.2
6.3
6.4
6.5
7
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.8
7.9
7.10
8
8.1
8.2
8.3
8.4
8.5
8.6
9
9.1
9.2
9.3
9.4
9.5
9.6
9.7
10
10.1
10.2
10.3
10.4
10.5
10.6
10.7
10.8
10.9
10.10
10.11
10.12
10.13
10.14
10.15
10.16
10.17
11
11.1
11.2
11.3
11.4
12
12.1
12.2
13
13.1
13.2
13.3
13.4
13.5
13.6
13.7
13.8
13.9
13.1
13.11
14
14.1
14.2
14.3
14.4
14.5
14.6
14.7
14.8
14.9
14.1
14.11
14.12
14.13
14.14
14.15
15
15.1
15.2
15.3
15.4
15.5
15.6
15.7
15.8
16
16.1
16.2
16.3
16.4
16.5
16.6
16.7

Cost & Pricing Requirement ID Requirements (All of the items apply to any subcontractors that work on the solution. )

General Features (Required)
1Cost and Pricing
1.1Application Costs
1.2Trainng Costs
1.3Implementation Costs
1.4Price by Module
1.5Intergration Costs
1.6Data Conversion
1.72019 Priorities
1.8Complete solution implementation
1.9Time, Attendance, Tax Modules 5 year costs
1.1Detail One time costs
1.11Detail ongoing costs
1.12Hardware Costs

Index

Core CapabilityMust Have
Configurable by VendorNice to Have
Configurable by City StaffNeed to Have (customizable in system)
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 .