3-Attachment 2 - Functional and Technical Requirements.xlsx
XLSX spreadsheet 28 KB Posted
- Attached to
- Salt Lake City Corporation Request for Proposals SLCI26092 Agenda and Minutes Software RFP
- Solicitation number
- SLCI26092
- Issued by
- Utah
About this file
This document is a Functional and Technical Requirements attachment for Salt Lake City Corporation's Request for Proposals SLCI26092 for Agenda and Minutes Software. The requirements specification outlines the software capabilities needed to manage public meeting agendas, minutes, and related documentation for municipal government bodies. The functional requirements encompass communications features including message distribution for meeting cancellations, subscription capabilities for interested parties, and document sharing; system capabilities such as website embedding, customization, searchability, and content redaction; mobile accessibility for viewing documents and videos across devices; reporting functions for tracking meetings and public hearing comments; integrations with conferencing platforms like Zoom and WebEx, YouTube for streaming, and document management systems such as Laserfiche; account management with separate workflows by public body; templating and version tracking for agendas and minutes; timestamps for video content with navigation capabilities; comprehensive voting functionality including vote tracking and remote voting; and live streaming with on-demand video availability. The specification identifies requirements as either mandatory or nice-to-have, with mandatory items being essential to contract award.
The technical requirements establish that the system must achieve 99.99% availability and implement robust security protocols including SSO/SAML authentication, two-factor authentication, TLS 1.2 encryption with 256-bit encryption standards, and comprehensive audit logging. Data management requirements mandate secure FTP or TLS 1.2 for all exchanges, support for real-time and batch processing via API web services or CSV/XLSX imports, and storage exclusively within the United States. Cloud or SaaS providers must maintain SOC 2 Type 1 or Type 2 certification and FIPS 140-2 or 140-3 compliance. The system must support multiple modern web browsers including Microsoft Edge, Google Chrome, Firefox, and Safari, with HTML5 and no additional plug-ins required. Multi-language support and Americans with Disabilities Act compliance are mandatory, along with responsiveness across iOS, Android, and desktop devices. The document establishes that all data ownership remains with the City, with provisions for data export and destruction certification upon contract termination.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 5-SLCI26092.docx | DOCX document | |
| 4-Attachment 4 - Score Sheet.xls | XLS spreadsheet | |
| 2-Attachment 3 - Cost Proposal.xlsx | XLSX spreadsheet | |
| 1-Attachment 1 - Sample Agreement.docx | DOCX document | |
| 6-Attachment 5 - Terms and Conditions Airport.docx | DOCX document | |
| 7-Confidential+and+Proprietary+Info+Declaration+Form (1) (2).pdf |
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
Functional Requirements
| Agenda and Minutes Software |
| Attachment 2 - Functional Requirements |
| Requirement ID | Topic | Internal (Logged in Users)/External | Requirement | Mandatory/Nice to Have | Public Body can complete task or Ticket/Support Required | Offeror Response | Offeror Narrative or Additional Comments |
| 1.1 | Communications | ||||||
| 1.1.1 | Communications | Internal/External | Ability to distribute messages in case of meeting cancellations or schedule changes that are sent based on public body. | Mandatory | |||
| 1.1.2 | Communications | Internal/External | Ability to post "banner" notice in case of meeting cancellation or schedule changes that are sent based on public body. | Nice to Have | |||
| 1.1.3 | Communications | External | Ability for interested parties to subscribe to updates based on public body. | Mandatory | |||
| 1.1.4 | Communications | External | Ability for interested parties to subscribe to updates based on meeting items. | Nice to Have | |||
| 1.1.5 | Communications | Internal/External | Ability to include direct links or published documents based on public body. | Mandatory | |||
| 1.1.6 | Communications | Internal | Ability for public body to customize email templates, add terms and conditions (acceptance) for data privacy, and an unsubscribe, etc. | Mandatory | |||
| 1.1.7 | Communications | External | Ability for interested parties to comment on meeting items through the system. | Nice to have. | |||
| 1.1.8 | Communications | External | Ability to share meeting information to social media accounts. | Nice to have. | |||
| 1.2 | System | ||||||
| 1.2.1 | System | Internal | Ability for system to be embedded in City's website. | Mandatory | |||
| 1.2.2 | System | Internal | Customization of portals for public body. | Nice to have. | |||
| 1.2.3 | System | Internal | Ability to view a preview before publishing. | Mandatory | |||
| 1.2.4 | System | Internal/External | Ability to create and share a hyperlink directly link to content in the system including draft areas for internal and external users. | Nice to have. | |||
| 1.2.5 | System | Internal | Ability to annotate and save records for each user. | Mandatory | |||
| 1.2.6 | Customization | Internal | Ability to customize documents including agendas by public body. For example, City logo, chair/vice chair names. | Mandatory | |||
| 1.2.7 | Extraction | Internal | Ability to extract content including but not limited to following requirements on the Utah public meeting website: https://www.utah.gov/pmn/ | Mandatory | |||
| 1.2.8 | Extraction | Internal | Ability to export agendas as rich text. | Mandatory | |||
| 1.2.9 | File Size | Internal | Describe file size allowance for each item as an attachment. | Mandatory | |||
| 1.2.10 | File Type | Internal | Describe acceptable file types for each item as an attachment. | Mandatory | |||
| 1.2.11 | Title Character Count | Internal | Describe character account for titles of each attachment. | Mandatory | |||
| 1.2.12 | Searchability | Internal | Ability for those on the system to be able to search agendas by keywords, dates, etc. | Mandatory | |||
| 1.2.13 | Searchability | Internal | Ability to prohibit searchability of content based on user group. | Mandatory | |||
| 1.2.14 | Searchability | Internal | Ability to secure from publication specific content by user group. | Mandatory | |||
| 1.2.15 | Redaction | Internal | Ability to redact documents within system. | Nice to have. | |||
| 1.3 | Mobile Accessibility | ||||||
| 1.3.1 | Mobile Accessibility | External | Ability for interested parties to view all documents and watch videos/multimedia via a mobile app. | Mandatory | |||
| 1.3.2 | Mobile Accessibility | External | Ability for interested parties to view all documents via a mobile app in different languages. | Nice to have. | |||
| 1.3.3 | Mobile Accessibility | Internal | Ability for internal users to access system through a mobile app. | Mandatory | |||
| 1.3.4 | Mobile Accessibility | External | Ability for mobile app to scale content and documents properly. | Mandatory | |||
| 1.4 | Reporting | ||||||
| 1.4.1 | Reporting | Internal | Ability to have reports that track number of public hearing comments. | Nice to have. | |||
| 1.4.2 | Reporting | Internal | Ability to track number of legislation passed by each public body. | Nice to have. | |||
| 1.4.3 | Reporting | Internal | Ability to track number of public hearings. | Nice to have. | |||
| 1.4.4 | Reporting | Internal | Ability track number of meetings by public body. | Nice to have. | |||
| 1.4.5 | Reporting | Internal | Ability to track and export start time, end time, and total meeting time. | Nice to have. | |||
| 1.5 | Integration | ||||||
| 1.5.1 | Integration | Internal | Ability to integrate with any hybrid meeting conference software (such as Zoom, WebEx). | Nice to have. | |||
| 1.5.2 | Integration | Internal | Ability to integrate with YouTube for streaming purposes. | Mandatory | |||
| 1.5.3 | Integration | Internal | Ability to integrate with electronic document records management system i.e. Laserfiche. | Mandatory | |||
| 1.5.4 | Integration | Internal | Ability to integrate with ShapeSLC or Marketing Salesforce. | Nice to have. | |||
| 1.6 | Account Management | ||||||
| 1.6.1 | Account Management | Internal | Ability to have separate accounts by public body. | Mandatory | |||
| 1.6.2 | Account Management | Internal | Ability to have separate workflows by public body. | Mandatory | |||
| 1.6.3 | Account Management | Internal | Ability to manage who can edit, view, or approve content. | Mandatory | |||
| 1.6.4 | Account Management | Internal | Ability to document who made changes to content and when. | Mandatory | |||
| 1.6.5 | Account Management | Internal | Ability to track items between different meetings and public bodies. | Mandatory | |||
| 1.6.6 | Account Management | Internal | Ability to create user groups with varying levels of security access across content types. | Mandatory | |||
| 1.7 | Templates | ||||||
| 1.7.1 | Templates | Internal | Ability to have stored, customized templates for content, meetings, and by public body. | Mandatory | |||
| 1.7.2 | Templates | Internal | Ability to add public body designed graphics with customized templates. | Mandatory | |||
| 1.8 | Version Tracking | ||||||
| 1.8.1 | Version Tracking | Internal | Ability to have version tracking for minutes. | Mandatory | |||
| 1.8.2 | Version Tracking | Internal | Ability to have version tracking for each agenda discussion item. | Nice to have. | |||
| 1.9 | Timestamps | ||||||
| 1.9.1 | Timestamps | Internal | Ability for system to create timestamps and populate timestamps across different content types. | Mandatory | |||
| 1.9.2 | Timestamps | Internal/External | Describe timestamp allowances regarding the use of duration of the video vs local time. | Nice to have. | |||
| 1.9.3 | Timestamps | Internal/External | Ability to jump to certain timestamps within content posted on the system. | Mandatory | |||
| 1.9.4 | Timestamps | Internal | Ability to jump to certain timestamps within content posted on YouTube. | Nice to have. | |||
| 1.10 | Voting Functionality | ||||||
| 1.10.1 | Voting Functionality | Internal | Ability to have voting functionality (track votes by individual with voting capabilities within each public body, be able to open vote, vote, close the vote, tally vote). | Mandatory | |||
| 1.10.2 | Voting Functionality | Internal | Ability for public bodies to track votes and enter into the system assigned to a voting individual. | Mandatory | |||
| 1.10.3 | Voting Functionality | Internal | Ability for voting individuals to vote through the system. | Mandatory | |||
| 1.10.4 | Voting Functionality | Internal | Ability to track activity on items including customization of motions. | Mandatory | |||
| 1.10.5 | Voting Functionality | Internal | Ability to customize voting options. List voting options (such as aye, nay, absent, and abstain). | Mandatory | |||
| 1.10.6 | Voting Functionality | Internal | Ability for voting member to remote vote through a login/app. | Nice to have | |||
| 1.10.7 | Voting Functionality | Internal | Ability to integrate hardware for voting members. | Nice to have | |||
| 1.10.8 | Voting Functionality | External | Ability for the public to view voting records. | Mandatory | |||
| 1.11 | Live Streaming and On-Demand Video | ||||||
| 1.11.1 | Live Streaming | Internal | Ability to upload a revised video. | Mandatory | |||
| 1.11.2 | Live Streaming | Internal | Ability for media team to be an active participant and broadcast to facilitate audio and camera control to the live stream. | Mandatory | |||
| 1.11.3 | Live Streaming | Internal | Ability for user friendly option for integrating audio and video. | Nice to have | |||
| 1.11.4 | Live Streaming | Internal | Ability for system to autoset timestamps in content after the fact. | Nice to have | |||
| 1.11.5 | Live Streaming | Internal | Ability for an in person/in room video conference with an administrator to run the meeting. | Mandatory | |||
| 1.11.6 | Live Streaming | Internal | Ability to pause and restart a meeting broadcast without creating a new video. | Mandatory | |||
| 1.11.7 | Live Streaming | Internal/External | Ability to have fast duplication or reset of an existing streaming meeting instance. | Nice to have | |||
| 1.11.8 | On-Demand Video | Internal/External | Ability to have on-demand video available through Offeror's system. | Mandatory | |||
| 1.12 | |||||||
| End or Termination of Contract | Internal | Ability to delete data at end or termination of contract. | Mandatory | ||||
| Retention Policy | Internal | Ability to restrict how long content is published on system. | Mandatory | ||||
| Retention Policy | Internal | Ability to set retention policies for deletion of public body content. | Nice to have |
Technical Requirements
| Agenda and Minutes Software RFP |
| Attachment 2 - Technical Requirements |
| Requirement ID | Topic | Response Type | Requirement | Offeror Response | Offeror Narrative or Additional Comments |
| 2.1 | Network Requirements | ||||
| 2.1.1 | Network Requirements | Narrative | Is there a VPN component to the system? If so, what type of VPN systems are proposed (site-to-site, IPSec, SSL/TLS, etc.)? Describe the VPN requirements in detail. | ||
| 2.1.2 | Network Requirements | Requirement | The system will have 99.99% availability. | ||
| 2.2 | Security | ||||
| 2.2.1 | Security | Requirement | Authentication of public body users (may not have City factor authentication) will be provided utilizing SSO/SAML authentication or a similar method. | ||
| 2.2.2 | Security | Requirement | Authentication of local or system account with 2FA. | ||
| 2.2.3 | Security | Requirement | System will utilize end-to-end encryption, TLS 1.2. | ||
| 2.2.4 | Security | Requirement | The end-to-end encryption will protect data both in-transit and at rest. | ||
| 2.2.5 | Security | Requirement | System uses 256 bit encryption. | ||
| 2.2.6 | Security | Requirement | As standard process, Offeror provides system administrator a step-by-step process for initial password setup. Admin must assign a password to the user when creating a user master record. Password must meet the internal requirements set by the system. | ||
| 2.2.7 | Security | Requirement | System provides the ability to support a centralized security administration function. | ||
| 2.2.8 | Security | Requirement | System provides the ability to create a Master Record/Role to enable the user to log onto the System and allow access to the functions and objects within the limits of the authorization profiles specified in the role. The user master record contains all information about the corresponding user, including the authorization profiles. | ||
| 2.2.9 | Security | Requirement | System provides the ability for System administrator to setup user-defined security hierarchy for role-based security. | ||
| 2.2.10 | Security | Requirement | System provides the ability to define the level of access for which a user is authorized (i.e. read-only or update). | ||
| 2.2.11 | Security | Requirement | System provides the ability to group users into classes and provide access restrictions by roles as defined. | ||
| 2.2.12 | Security | Requirement | System provides the ability to generate reports to review authorization profiles given to the users defined in the System. | ||
| 2.2.13 | Security | Requirement | System provides the ability to check for failed password logon attempts and increase the unsuccessful logon counter for the affected user master record. | ||
| 2.2.14 | Security | Requirement | System provides the ability to define the number of retries allowed before terminating the logon attempt and disabling the account when a user enters an incorrect password. | ||
| 2.2.15 | Security | Requirement | System provides the ability to lock a user account after a specified period of time with no logins from the user account. | ||
| 2.2.16 | Security | Requirement | System provides the ability to record/capture the following information about each unauthorized access attempt and/or limit the information to any one of the following individual fields: user ID, workstation, date, time, transaction type (menu, file, screen, field), access type (inquiry, modify, etc.). | ||
| 2.2.17 | Security | Requirement | System provides the ability to support secure access to the database, so that only authorized users are allowed to access the database, and report attempts to access the database by unauthorized users. | ||
| 2.2.18 | Security | Requirement | System provides the ability to prevent passwords from being printed or displayed. Mask passwords as they are being typed. | ||
| 2.2.19 | Security | Requirement | System provides the ability to encrypt passwords while stored so they cannot be viewed. No clear-text passwords. | ||
| 2.2.20 | Security | Requirement | System allows multiple concurrent user sessions | ||
| 2.2.21 | Security | Requirement | System provides the ability to disconnect a user already logged on. | ||
| 2.2.22 | Security | Requirement | System provides the ability to define and determine idle time based on user groups, and time out or suspend a user after a configurable period of idle time. This time out requires the user to re-enter their password before continuing. | ||
| 2.2.23 | Security | Requirement | System will provide an audit log of user activity. | ||
| 2.2.24 | Security | Narrative | If the System uses a 'System account' or 'service accounts', describe the process to change the account(s) passwords. | ||
| 2.2.25 | Security | Narrative | Describe how incidents, ransomware, and breaches are detected, how and when customers are notified, insurance coverage, and how incidents and breaches are remediated. | ||
| 2.3 | Data | ||||
| 2.3.1 | Data | Requirement | All data is exchanged using secure FTP, TLS 1.2 or better. | ||
| 2.3.2 | Data | Requirement | Data exchange can be supported in real-time and by batch. | ||
| 2.3.3 | Data | Narrative | Any data exchange that utilizes a batch process can be scheduled and automated. Thus, not relying on any kind of manual intervention/push. | ||
| 2.3.4 | Data | Narrative | Data can be imported via batch files including csv, txt, and xlsx. | ||
| 2.3.5 | Data | Narrative | Data can be exchanged using API web services. Provide details regarding your web service protocols in the Narrative column. | ||
| 2.3.6 | Data | Narrative | What type of redundancy does System provide? | ||
| 2.3.7 | Data | Narrative | If an interfacing system does not support API or web services, describe how integrations would be developed in the Narrative column. | ||
| 2.3.8 | Data | Narrative | Describe your business continuity, data recovery, cyber event, and data availability processes. | ||
| 2.3.9 | Data | Narrative | Describe your data center disaster recovery procedures. | ||
| 2.3.10 | Data | Requirement | The awarded Offeror will agree to contract language which stipulates that the ownership of all data will remain with the City. At termination of the contract, the Offeror will allow the City to export the data at no additional cost. After export is complete, the Offeror will conduct a data destruction and provide a certification of disposition. | ||
| 2.3.11 | Data | Requirement | Due to differing privacy standards from country to country, all data must be stored and maintained in the US only. | ||
| 2.3.12 | Data | Requirement | A Cloud or SaaS provider must be SAS 70/SSAE 16/SSAE 18 (SOC2, Type 1 or Type 2) FIPS 140-2 or FIPS 140-3 certified and will agree to provide the latest audit reports (and bridge letter where applicable). | ||
| 2.3.13 | Data | Requirement | System will use date effective records or audit tables for historical reporting that record both date and time. | ||
| 2.3.14 | Data | Narrative | Describe how the System prevents multiple users in the internal System from editing the same record concurrently. If multiple users can edit the same record at the same time, describe how the System resolves data conflicts. | ||
| 2.4 | Interface Management | ||||
| 2.4.1 | Interface Management | Narrative | Explain the approach and any limitations to interface with other tools/software. | ||
| 2.4.2 | Interface Management | Narrative | Describe how the System enables staff to monitor and troubleshoot interfaces. | ||
| 2.4.3 | Interface Management | Narrative | List and describe the private, partner, and/or public APIs available with System. Provide API documentation for each API and confirm in the Narrative field that this has been provided. | ||
| 2.4.4 | Interface Management | Narrative | Describe the process to develop a new system interface. | ||
| 2.5 | Identity Provider | ||||
| 2.5.1 | Identity Provider | Narrative | Explain how the System will determine a threat during the identification process (including Malware, DDoS, Brute-Force). | ||
| 2.5.2 | Identity Provider | Narrative | Describe how the System maintains a record of previous threats including the retention period. | ||
| 2.5.3 | Identity Provider | Narrative | Describe how the System will support multi-factor authentication. City's preference is Microsoft Entra ID. | ||
| 2.6 | System Tools | ||||
| 2.6.1 | System Tools | Narrative | Describe the capabilities for the team to add a data fields to forms/tables, including the formatting of the field, reporting capability, functionality, interfacing, etc. without customizations of the System. Include how this impacts upgrades. | ||
| 2.6.2 | System Tools | Narrative | Describe the System's capabilities for archive/purge of system data and logs. Also, include the suggested best practice for data archive/purge as it pertains to maintaining optimal System performance. | ||
| 2.7 | System Maintenance | ||||
| 2.7.1 | System Maintenance | Narrative | Describe the process to apply a System updates (hotfix, point patch, minor version update) including level of effort for staff, time, and impact to users. | ||
| 2.7.2 | System Maintenance | Narrative | Describe the process to apply a major version update including level of effort for staff, time, and impact to users. | ||
| 2.7.3 | System Maintenance | Narrative | Describe the process for restoring and/or cloning data from Production to Test environments. | ||
| 2.7.4 | System Maintenance | Narrative | Describe how many environments (Prod, Test, Dev) will be delivered as part of the System. | ||
| 2.7.5 | System Maintenance | Narrative | List the estimated price of adding an additional environment to the System. | ||
| 2.7.6 | System Maintenance | Narrative | Describe how system updates can be evaluated by SLC prior to being applied to the production environment. | ||
| 2.7.7 | System Maintenance | Narrative | Describe how modifications or customizations to the System will be incorporated into the next released minor version of the System. | ||
| 2.7.8 | System Maintenance | Narrative | Provide a sample SLA and confirm in the Narrative field that this has been provided. | ||
| 2.8 | Supported Web Browsers | ||||
| 2.8.1 | Supported Web Browsers | Requirement | If the System is accessed via web browser it must use HTML5 with no additional plug ins. | ||
| 2.8.2 | Supported Web Browsers | The System will support the multiple modern web browsers for both desktop and mobile devices including the following: | |||
| 2.8.3 | Supported Web Browsers | Requirement | Microsoft Edge | ||
| 2.8.4 | Supported Web Browsers | Requirement | Google Chrome | ||
| 2.8.5 | Supported Web Browsers | Requirement | Firefox | ||
| 2.8.6 | Supported Web Browsers | Requirement | Safari | ||
| 2.8.7 | Supported Web Browsers | Narrative | Other (Specify in the notes column) | ||
| 2.9 | Customer Self Service | ||||
| 2.9.1 | Customer Self Service | Narrative | The published website has ability to be viewed in different languages. | ||
| 2.9.2 | Customer Self Service | Narrative | The System provides multi-lingual support for both internal and external users. | ||
| 2.9.3 | Customer Self Service | The responsive design or the app design will support multiple device types, including the following: | |||
| 2.9.4 | Customer Self Service | Requirement | iOS devices as currently supported by Apple. | ||
| 2.9.5 | Customer Self Service | Requirement | Android devices from various manufacturers currently supported by that manufacturer. (Specify in the notes column) | ||
| 2.9.6 | Customer Self Service | Requirement | Desktop Computers utilizing a supported browser. | ||
| 2.10 | |||||
| 2.10.1 | Americans Disabilities Act | Requirement | The System and related records must comply with the Americas Disability Act accessibility requirements. | ||
| 2.10.2 | Telephone Consumer Protection Act | Requirement | The System will comply with Federal Communication Commission (FCC) regulations. | ||
| 2.10.3 | Salt Lake City Corporation Language Access Administrative Policy | Requirement | The System will comply with the Salt Lake City Corporation Language Access Administrative Policy found here: |
https://codelibrary.amlegal.com/codes/slc_utpolicy/latest/saltlakecity_manual_ut/0-0-0-10293
Formulas
| Public Body can complete task or Ticket/Support Required | Offeror Response |
| Public Body | Base Functionality - Proposed Version |
| Ticket Needed | Base Functionality - Upcoming Version |
| New Modification Required | |
| Cannot Meet Requirements |
File details come from the government source that posted it. Updated .