125DT036_-_Mass_Notifications_Software-_Compliance_Matrix_V.2.xlsx
XLSX spreadsheet 36 KB Posted
- Attached to
- Mass Notification Software Upgrade State and local contract opportunity
- Solicitation number
- RFP 125DT036
- Issued by
- Denver County, Denver City, Colorado
About this file
This document is a Compliance Matrix for a Mass Notification Software procurement by the Regional Transportation District (RTD) in Colorado. The matrix details 140 functional requirements for a comprehensive mass notification system upgrade, covering areas such as administration, dispatch operations, system integrations, reporting, auditing, and project management. The project aims to replace the existing ReadyOp system with a modern, integrated platform that supports multi-channel messaging across bus dispatch, rail operations, transit police, and emergency management teams. Key project components include a project kickoff meeting within 21 days of Notice to Proceed, weekly progress meetings, a detailed project schedule, and a phased implementation approach with comprehensive testing and training requirements.
The contract includes extensive technical specifications for the notification system, such as role-based permissions, geofence-based alerts, integration with HR and dispatch systems, and robust reporting capabilities. The solution must support various communication channels including SMS, email, public address systems, and radio notifications, with specific requirements for incident severity categorization and escalation protocols. Service and support terms include 24x7 technical support, a detailed Service Level Agreement with response times based on issue severity, and ongoing maintenance with prompt patch and upgrade commitments. The contractor will be responsible for providing comprehensive documentation, training materials, and a fully functional training environment, with all materials becoming RTD's property upon contract completion.
View the file
Other files for this state and local contract opportunity
| File | Type | Posted |
|---|---|---|
| Mass_Notification_Software_Upgrade_(Addendum_#4_Revision).pdf | ||
| 125DT036_-_Form_of_Contract_-_Mass-Notification-Software-Upgrade_-_FINAL.pdf | ||
| 125DT036_Statement_of_Work_Mass_Notifications_Software_Upgrade_-_Final.pdf | ||
| 125DT036_-Payment_Milestones_Matrix_-_Mass_Notifications_Software_Upgrade.pdf |
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Sheet1
| This Requirements Compliance Matrix form must be completed and submitted with your proposal. | Company Name: |
| Note: Please refer to the RFP Statement of Work, Section 4, for additional Project Requirement information. | Please enter Company Name Here |
| Date of Proposal: | |
| Instructions: For each table of requirements listed below please respond with one of the following response codes: | Please enter Proposal Date Here |
| Response | Definition |
| Code | |
| FC | Fully Compliant – Proponent fully complies with requirement. Responses that are qualified by exceptions or limitations, etc. in the Compliance Matrix shall be considered the equivalent of “NC” (does not comply). |
| CM | Complies with Modified Requirement – Proponent shall provide modified requirement language to which they commit to comply. The “CM” shall be equivalent to a response of “FC” if RTD opts to change the requirement as proposed, or to a response of “NC” if RTD opts to not change the requirement. |
| If complete alternate requirement wording is not proposed in conjunction with a “CM” response, the response shall be considered equivalent to a response of “NC” to the requirement as stated in the RFP. RTD alone shall be the judge of the completeness and appropriateness of alternate requirement language. | |
| NC | Does Not Comply – Proponent does not comply with the requirement. Accompanying comments are discouraged. |
| Response | |||||
| ID | Name | Type | Description | Code | Comments |
| REQ-1 | Administration and Management | Functional | The ability to enable role-based notification permissions to control who can send, receive, and acknowledge different types of alerts, ensuring compliance with internal policies. | ||
| REQ-2 | Administration and Management | Functional | The ability to bulk upload and remove users from notification lists using spreadsheet imports and Human Resources (HR) system integrations. | ||
| REQ-3 | Administration and Management | Functional | The ability to automate removal of inactive users based on Human Resources (HR) system employment status, ensuring separated employees no longer receive notifications. | ||
| REQ-4 | Administration and Management | Functional | The ability to send targeted notifications based on predefined geofences, allowing location-based alerts for incidents affecting specific facilities, transit routes, and mobile personnel. (Ex. Support for temporary locations and mobile tracking of personnel, rather than just fixed assigned locations.) | ||
| REQ-5 | Administration and Management | Functional | The ability to filter notification recipients based on their real-time or last-known location, ensuring that only personnel within or near the affected area receive relevant alerts. (Ex. If an evacuation is required for a specific facility, only employees currently inside or immediately near that facility receive alerts.) | ||
| REQ-6 | System Integrations And Automations | Functional | The ability to integrate contact lists with Computer-Aided Dispatch (CAD) for real-time incident alerts, ensuring dispatchers have up-to-date contact information when responding to emergencies. | ||
| REQ-7 | Administration and Management | Functional | The ability to allow notification administrators to manage contacts centrally | ||
| REQ-8 | Administration and Management | Functional | The ability to allow users to opt into or opt out of notification groups | ||
| REQ-9 | Bus Dispatch Operations | Functional | The ability to integrate bus and rail dispatcher notifications with mass notification systems to ensure real-time dissemination of service-impacting alerts across all transit operations. | ||
| REQ-10 | Bus Dispatch Operations | Functional | The ability to allow dispatchers to send alerts about facility maintenance issues, including predefined categories such as Heating, Venting, and Air Conditioning (HVAC) failures, electrical malfunctions, and safety hazards, ensuring proper escalation. | ||
| REQ-11 | Bus Dispatch Operations | Functional | The ability to categorize emergency calls using pre-set priority levels (Low, Priority Request to Talk (PRTT), Emergency Silent Alarm) | ||
| REQ-12 | System Integrations And Automations | Functional | The ability to integrate the Computer-Aided Dispatch (CAD) Automatic Vehicle Location (AVL) alert system to trigger priority alerts directly | ||
| REQ-13 | Bus Dispatch Operations | Functional | The ability to allow delegated personnel to initiate notifications during emergencies | ||
| REQ-14 | System Integrations And Automations | Functional | The ability to allow operators to send emergency alerts via radio, which automatically triggers a mass notification in targeted areas | ||
| REQ-15 | Bus Dispatch Operations | Functional | The ability to escalate notifications based on incident severity | ||
| REQ-16 | Bus Dispatch Operations | Functional | The ability to notify different teams based on a predefined escalation process, restricting alerts to relevant personnel depending on the severity of the situation. (Ex. A "Red" list for life-threatening emergencies and a "Yellow" list for lower-priority incidents. Selecting one automatically filters out the other to prevent unnecessary notifications.) | ||
| REQ-17 | Reporting And Auditing | Functional | The ability to provide real-time updates on notifications for all recipients | ||
| REQ-18 | System Integrations And Automations | Functional | The ability to integrate notifications with Public Announcement (PA) systems in transit facilities | ||
| REQ-19 | Bus Dispatch Operations | Functional | The ability to enable pre-filled notification templates based on event types | ||
| REQ-20 | Facility Maintenance Alerts | Functional | The ability to escalate facility-related alerts to relevant departments automatically, ensuring that unresolved issues are reassigned and elevated based on severity thresholds (e.g., fire hazards, elevator failures). | ||
| REQ-21 | Facility Maintenance Alerts | Functional | The ability to enable supervisors to send quick facility-wide notifications via Short Message Service (SMS), email, and in-system alerts to all relevant staff, allowing rapid coordination in emergency situations. | ||
| REQ-22 | Facility Maintenance Alerts | Functional | The ability to create notification groups for facility maintenance teams | ||
| REQ-23 | Facility Maintenance Alerts | Functional | The ability to send follow-up notifications when maintenance is complete | ||
| REQ-24 | Facility Maintenance Alerts | Functional | The ability to integrate Public Announcement (PA) system notifications for maintenance alerts | ||
| REQ-25 | Information Technology (IT) Notifications | Functional | The ability to automate Information Technology (IT) incident notifications based on severity level (e.g., Priority 1 (P1) for critical outages, Priority 2 (P2) for degraded performance), ensuring impacted users receive timely alerts via multiple channels. | ||
| REQ-26 | Reporting And Auditing | Functional | The ability to provide an audit trail of Information Technology (IT) incident notifications, logging timestamps, recipients, and acknowledgment status to support compliance and post-incident analysis. | ||
| REQ-27 | Information Technology (IT) Notifications | Functional | The ability to categorize Information Technology (IT) service disruptions as Priority 1 (P1), Priority 2 (P2), or Priority 3 (P3), ensuring clear prioritization of technical issues. | ||
| REQ-28 | System Integrations And Automations | Functional | The ability to integrate Information Technology (IT) service notifications with broader mass notification systems, ensuring that service disruptions affecting transit operations trigger appropriate alerts. | ||
| REQ-29 | Information Technology (IT) Notifications | Functional | The ability to allow employees to opt into different Information Technology (IT) notification severities by administration allowances and role assignments | ||
| REQ-30 | Mass Notification Processing | Functional | The ability to provide a standardized notification template across departments that prepopulates incident details such as location, severity, and response actions, reducing manual input errors. | ||
| REQ-31 | Mass Notification Processing | Functional | The ability to categorize notifications based on incident severity (Red: life-threatening, Yellow: significant impact, Blue: departmental updates), ensuring consistent messaging across the agency. | ||
| REQ-32 | Mass Notification Processing | Functional | The ability to automate mass notifications based on preconfigured incident types, allowing dispatchers to send alerts with minimal manual intervention. | ||
| REQ-33 | Reporting And Auditing | Functional | The ability to track acknowledgment rates for emergency notifications by logging user responses and providing real-time dashboards for command staff. | ||
| REQ-34 | Mass Notification Processing | Functional | The ability to send predefined emergency alerts based on policy-defined criteria (e.g., active shooter, fire evacuation), reducing response times during critical incidents. | ||
| REQ-35 | Mass Notification Processing | Functional | The ability to classify notifications by priority (Red: Immediate Response, Yellow: Important but not urgent) to standardize communication protocols across the organization. | ||
| REQ-36 | Mass Notification Processing | Functional | The ability to ensure that all mass notifications initiated by any communication center are automatically relayed to Transit Police Communications for situational awareness and oversight. (Ex. When a facility incident or security event is reported, notifications are automatically shared with transit police command staff before being sent to the broader recipient list.) | ||
| REQ-37 | Mass Notification Processing | Functional | The ability to automatically convert mass notifications text to speech for audio and Public Announcement (PA) channels. {Ex. Supporting Short Message System (SMS), email, in-app alerts, and text-to-speech audio messages for Public Announcement (PA) systems in transit facilities.} | ||
| REQ-38 | Mass Notification Processing | Functional | The ability to send attachments such as images or documents with mass notifications | ||
| REQ-39 | Mass Notification Processing | Functional | The ability to allow manual selection of additional recipients to mass notifications, as needed | ||
| REQ-40 | Mass Notification Processing | Functional | The ability to define different notification groups by location and incident type | ||
| REQ-41 | Mass Notification Processing | Functional | The ability to assign specific notification recipients based on operational divisions | ||
| REQ-42 | Mass Notification Processing | Functional | The ability to allow dispatchers to send notifications only to relevant personnel | ||
| REQ-43 | Mass Notification Processing | Functional | The ability to define and manage notification audiences based on the severity of the emergency | ||
| REQ-44 | Reporting And Auditing | Functional | The ability to provide real-time dashboard visualization of notification reach | ||
| REQ-45 | Mass Notification Processing | Functional | The ability to store and manage multiple notification templates | ||
| REQ-46 | Mass Notification Processing | Functional | The ability to allow supervisors to create and modify contact lists for notification routing | ||
| REQ-47 | Mass Notification Processing | Functional | The ability to escalate incidents requiring mass notification via preconfigured escalation pathways | ||
| REQ-48 | Reporting And Auditing | Functional | The ability to maintain historical logs of mass notifications for compliance and auditing | ||
| REQ-49 | Reporting And Auditing | Functional | The ability to allow supervisors to audit past notifications for compliance, including message content, recipients, and acknowledgment records. | ||
| REQ-50 | Reporting And Auditing | Functional | The ability to archive notifications for compliance and record-keeping, ensuring that all alerts are stored for post-incident review and legal requirements. Ex. Three year minimum | ||
| REQ-51 | Reporting And Auditing | Functional | The ability to provide statistics on notification delivery and failure rates, identifying issues such as message bounces, blocked numbers, or unread messages. | ||
| REQ-52 | Reporting And Auditing | Functional | The ability to track and report average call response times and resolution times | ||
| REQ-53 | Reporting And Auditing | Functional | The ability to review notification logs for audit and compliance checks | ||
| REQ-54 | Reporting And Auditing | Functional | The ability to track and log notification recipients who did not receive or acknowledge alerts | ||
| REQ-55 | Reporting And Auditing | Functional | The ability to track and report the time between event occurrence and notification sent | ||
| REQ-56 | Reporting And Auditing | Functional | The ability to display response rates for critical notifications | ||
| REQ-57 | Reporting And Auditing | Functional | The ability to provide a real-time dashboard for notification monitoring | ||
| REQ-58 | Security Management | Functional | The ability to prevent unauthorized users from modifying notification groups | ||
| REQ-59 | System Integrations And Automations | Functional | The ability to integrate notification system with HR systems for automatic personnel updates, ensuring new hires and role changes are reflected in all systems at once | ||
| REQ-60 | System Integrations And Automations | Functional | The ability to support mobile-friendly mass notification access, ensuring staff can send and receive alerts via smartphones and tablets. | ||
| REQ-61 | System Integrations And Automations | Functional | The ability to support two-way messaging for mass notifications, allowing recipients to acknowledge or respond to alerts when necessary. | ||
| REQ-62 | System Integrations And Automations | Functional | The ability to integrate notification system with existing radio systems to enable voice-based mass notifications for personnel using radio communications. | ||
| REQ-63 | System Integrations And Automations | Functional | The ability to integrate notification system with phone systems for voice notifications, ensuring alerts can be sent via automated phone calls. | ||
| REQ-64 | System Integrations And Automations | Functional | The ability to automate mass notifications when specific triggers are met, such as weather alerts, system outages, or security breaches. | ||
| REQ-65 | System Integrations And Automations | Functional | The ability to integrate notification groups with Active Directory | ||
| REQ-66 | System Integrations And Automations | Functional | The ability to consolidate duplicate notification lists and prevent redundant notifications | ||
| REQ-67 | System Integrations And Automations | Functional | The ability to send mass notifications to onboard bus operator dashboards | ||
| REQ-68 | System Integrations And Automations | Functional | The ability to provide API-based integration for mass notifications | ||
| REQ-68.1 | System Integrations And Automations | Functional | The ability to integrate SIP-based PA system communications for pre-recorded announcements. | ||
| REQ-69 | Kick-off Meeting | Project Management | A Project Kickoff Meeting, coordinated with the RTD Project Manager, shall be scheduled within seven (7) days after Notice to Proceed (NTP) and conducted within twenty-one (21) days. The Project Kickoff Meeting will be conducted by the Contractor and the RTD Project Manager at RTD offices, through Microsoft Teams, or other high-quality teleconferencing approach. | ||
| REQ-70 | Project Meetings | Project Management | The contractor shall schedule and facilitate Progress Meetings held between the Contractor and RTD on a weekly or every other week basis, as deemed necessary by RTD, for the purpose of reviewing progress, coordinating activities, and other project activities that cannot be resolved by correspondence. The timing of these meetings shall be conducted at RTD’s sole discretion, based on the nature of the current project activities. These meetings may be at RTD offices, through Microsoft Teams, or other high-quality teleconferencing approach. | ||
| REQ-71 | Project Meeting Agendas | Project Management | Agendas for the Progress Meetings will be prepared by the Contractor and may include any topics that the Contractor's Project Manager determines to be relevant to the project. The Contractor shall insure those persons knowledgeable in the topics to be discussed, including subcontractors, subject matter experts, and/or technical representatives, are present at all necessary meetings. Agendas will be submitted at least two (2) business days prior to the meeting. | ||
| REQ-72 | Meeting Summaries | Project Management | Meeting summaries shall be taken at all meetings. Summaries shall include a summary of all topics discussed, a listing of all understandings and agreements reached, and an updated Action Item List (AIL). Unless otherwise agreed, the Contractor shall be responsible for taking all meeting summaries. The format for the meeting summaries shall be developed based on input from RTD. Completed meeting summaries shall be uploaded to the RTD Teams project site by the Contractor. | ||
| REQ-73 | Meeting Summaries | Project Management | The meeting summaries shall be distributed to all attendees for review within three (3) business days from the end of the meeting. | ||
| REQ-74 | Action Item List | Project Management | During meetings, action items will be identified, with each action item assigned to an individual for disposition by a pre-determined response date. These action items shall be maintained and updated throughout the project by the Contractor, in an Action Item List (AIL). The AIL format will be mutually agreed upon by the Contractor and RTD. The AIL shall be maintained in the RTD Teams project site. | ||
| REQ-75 | Issue Tracking systems | Project Management | The Contractor shall provide RTD key personnel access to any issue tracking system used by the Contractor to support the project. The Contractor will provide no less than monthly a status report of all tickets. | ||
| REQ-76 | Monthly Status Report | Project Management | Contractor shall provide to the RTD Project Manager a status report monthly highlighting key accomplishments, risks, issues, and milestones/deliverables updates. The monthly status reports shall be uploaded by the Contractor to the RTD Teams project site. Status reports shall be uploaded by the Contractor to the RTD Teams project site. | ||
| REQ-77 | Invoice Documentation | Project Management | The Contractor shall keep and maintain reasonably complete and reliably detailed records of milestones achieved in performing the Contract, including records of productivity to identify basis for payment, sufficient to evaluate the accuracy, completeness, and currency of the costs or prices. | ||
| REQ-78 | Project Schedule | Project Management | Within thirty (30) days after Notice to Proceed (NTP), the Contractor shall furnish, to RTD for RTD’s approval, a detailed Project Schedule. The detailed Project Schedule shall be based on critical-path-method and constructed using Microsoft Project or RTD approved substitute. The project schedule shall include both Contractor and RTD tasks. The project schedule shall be maintained on the RTD Teams project site. | ||
| REQ-79 | Project Schedule | Project Management | The detailed Project schedule shall show start and completion of the work with dependencies for each activity and shall be properly ordered and sequenced. It shall identify all major work tasks including critical events of design, procurement, delivery schedule, installation, testing, and integration, and shall identify interface activities, subcontractor contributions and submittals, RTD inspections, tests, and approvals as may be required by this document, additional details shall be provided, such as: |
A clear description of the activity, including its location
· The duration expressed in full working days
· A responsibility for work denoting the Contractor, a subcontractor, RTD, or entity performing the activity
· The quantity of material, in units
· The integer percent complete representing the installed progress
· The actual start and finish dates Requirements and events which impose limitations, as well as dates and milestones which constrain the time, shall be clearly identified.
| REQ-80 | Project Schedule Updates | Project Management | The Contractor shall be required to submit project schedule updates on at least a monthly basis. More frequent near-term schedule updates may be required, if deemed advantageous by RTD for monitoring the progress of specific phases of the project. |
| REQ-81 | Site Visits | Project Management | The Contractor shall schedule and conduct site visits with the RTD PM with at least two (2) weeks notice or at the discretion of the RTD PM. |
| REQ-82 | Personnel | Project Management | All personnel assigned by the Contractor shall display appropriate identification while on RTD property and adhere to all RTD Rules and Regulations. |
| REQ-83 | Project Communications | Project Management | All email communications from the Contractor shall originate from accounts that are owned and managed by the vendor through access management controls. |
| REQ-84 | Project Communications | Project Management | Within thirty (30) days of Notice to proceed (NTP), the Contractor shall provide a RACI (Responsible, Accountable, Consulted, and Informed) Chart/Matrix outlining responsibilities, along with Contractor’s escalation procedure, including contact names and information for each level of escalation. This shall be updated by the Contractor within one week of any changes in key personnel. |
| REQ-85 | Project Communications | Project Management | The Contractor shall promptly notify the RTD PM of any problems or difficulties that may affect the timely or effective completion of the project or any scheduled deliverables. |
| REQ-86 | Project Communications | Project Management | The Contractor shall coordinate activities with RTD PM regarding affected RTD business units and personnel, and with external individuals and organizations. |
| REQ-87 | Subject Matter Experts | Project Management | The Contractor shall make all subject matter experts available - when required or requested. |
| REQ-88 | Quality Assurance | QA | The Contractor shall plan, establish, and maintain a Quality Assurance (QA) program. The Contractor’s Quality Assurance (QA) program shall be imposed upon all entities within the Contractor’s organization and on all subcontractors whenever contract work is performed. |
| REQ-89 | Quality Assurance | QA | A Quality Assurance (QA) Program Plan shall be submitted for review within 30 days of Notice to Proceed (NTP). The Quality Assurance (QA) Program Plan shall describe the methods for planning, implementing, and maintaining quality, schedules, and cost. The Quality Assurance (QA) Program Plan shall contain a company policy statement that clearly defines the authority and responsibilities of Quality Assurance (QA) personnel. |
| REQ-90 | Training Program and Schedule | Training | The Contractor shall work with RTD to develop a Training Program and Schedule that describes: |
·1. A plan for developing or customizing course material
2. An overview of delivery methods for each course, including target audience, prerequisites objectives and outcome
3. An evaluation plan, including criteria for success of the course, based upon the goals and objectives, and evaluation steps and instruments to be employed
4. A proposed schedule for each class, keyed to the implementation schedule and constrained by availability of trainees away from regular duties
5. All materials required to conduct the training
| REQ-91 | Training Instructors | Training | The Contractor is responsible for ensuring that the instructors teaching these courses are not only familiar with technical information but are able to use proper methods of instruction, training aids, audiovisuals and other materials to provide for effective training. All of the instructors provided by the Contractor shall be fully capable of transmitting in‐depth technical information that can be clearly understood by RTD participants. RTD shall have the right to direct that an instructor be replaced for cause, at no cost or schedule impact. |
| REQ-92 | Training | Training | The Contractor shall train RTD-designated personnel to operate, administrate, and maintain the Contractor-provided solution as required. |
| REQ-93 | Training | Training | Training shall include solution demonstrations. |
| REQ-94 | Training Environment | Training | The Contractor shall provide RTD with a fully functional training environment that mirrors production for training on the system before go-live. |
| REQ-95 | Training Materials | Training | All training materials shall become the property of RTD at the conclusion of training. |
| REQ-96 | Training Materials | Training | RTD shall retain access to all online training courses and/or materials for the length of the contract. |
| REQ-97 | Training Materials Language | Training | The training presentations and material shall be in English. |
| REQ-98 | Training Approval | Training | Training curricula, presentations, and/or materials shall be provided to RTD for review a minimum 30 days prior to commencement of training. No training shall commence until these items have been approved by RTD. |
| REQ-99 | Training Location | Training | The Contractor shall provide instructor-led on-site training in the Denver, Colorado region or remote training as agreed upon with RTD. |
| REQ-100 | Recording Training | Training | The Contractor shall permit RTD to record the training sessions for future in-agency training purposes. |
| REQ-101 | Additional Training | Training | The Contractor shall provide additional training to the original trainees after System Acceptance at no additional cost if major modifications, as defined by RTD, are made to the solution after the initial training due to solution upgrades or changes made under warranty; and/or System Acceptance occurs at least three (3) months after the completion of training, due to delays for which the Contractor is responsible. |
| REQ-102 | Support Resources | Support and Maintenance | The Contractor shall provide phone and email support to RTD 24x7 to assist with any issues during the term of the contract. |
| REQ-103 | Service Level Agreement | Support and Maintenance | The Contractor shall adhere to the following Service Level Agreement (SLA) for any issues with the Solution once implemented. |
- Severity 1 - Total System Error ‐ RTD will call the Contractor Support Line. This first line response will log the call, and offer resolution, if possible, within one (1) service or working hour. If resolution is not possible, within two (2) service or working hours a qualified technician will access the system and diagnose the problem. A resolution strategy will be presented to RTD that will detail the scope and duration of the solution.
- Severity 2 - Severe Impact on System ‐ RTD will call the Contractor Support Line. This first line response will log the call, and offer resolution, if possible, within two (2) service or working hours. If resolution is not possible, within four (4) service or working hours a qualified technician will access the system and diagnose the problem. A resolution strategy will be presented to RTD that will detail the scope and duration of the solution.
- Severity 3 - Minor Impact on System ‐ RTD will call the Contractor Support Line during regular working hours. This first line response will log the call, and offer resolution, if possible, within one (1) working day. If resolution is not possible, within ten (10) working days a qualified technician will access the system and diagnose the problem. A resolution strategy will be presented to RTD that will detail the scope and duration of the solution.
- Severity 4 - Watch Status ‐ RTD will call the Contractor Support Line during regular working hours. This first line response will log the call, and offer resolution, if possible, within one (1) working day. If resolution is not possible, within ten (10) working days a qualified technician will diagnose the problem. The item will remain open until it can be reproduced or more information can be gathered. These items will be reviewed monthly to assess the need to remain on the open list.
| REQ-104 | Update Schedule | Support and Maintenance | Contractor shall provide annual schedule and monthly update reports of upcoming application updates (e.g. monthly, quarterly, annually) and end-of-life notices. |
| REQ-105 | Release Notes | Support and Maintenance | Contractor shall provide software update release notes in advance of the receipt/application of all enhancements so users can test and evaluate changes. |
| REQ-106 | Release Notes | Support and Maintenance | Contractor shall include, with release notes, the expected time required for any particular update to complete. (e.g. expected downtime) |
| REQ-107 | Outages | Support and Maintenance | The Contractor shall proactively (at least 2 weeks in advance) alert RTD to any planned updates and outages to the system. |
| REQ-108 | Outage/Update Planning | Support and Maintenance | The Contractor shall reasonably plan, with RTD staff, for appropriate timing of any planned updates and outages to the system. |
| REQ-109 | Support and Maintenance | Support and Maintenance | Contractor shall provide a method/process for application on the Google/Apple store updates that ensures all devices (including mobile devices in the field) and the cloud applications have received updates (e.g. RTD will utilize the application 24 x 7). |
| REQ-110 | Preventive Maintenance | Support and Maintenance | Preventive maintenance of the System and its components shall be performed by the Contractor. |
| REQ-111 | Preventive Maintenance | Support and Maintenance | The Contractor shall schedule all preventive maintenance at the convenience of and with the approval of RTD. |
| REQ-112 | Preventive Maintenance | Support and Maintenance | This maintenance shall be limited to the equipment and software supplied under this contract. |
| REQ-113 | Preventive Maintenance | Support and Maintenance | A detailed description of all preventative maintenance tasks, procedures, tests, and schedules shall be provided to RTD for quality control. |
| REQ-114 | Patching/Upgrades | Support and Maintenance | Contractor shall maintain all patches and upgrades to all software and never be more than 1 (one) month behind on upgrades and patches recommended by Operating System and Database software providers |
| REQ-115 | Patching/Upgrades | Support and Maintenance | Contractor shall provide any and all software updates required to run the latest Operating System or Database version within 1 (one) or 2 (two) years of its release. |
| REQ-116 | Compatibility with 3rd party software | Support and Maintenance | Contractor shall maintain compatibility with Contractor-provided 3rd-party software updates (Prime and their sub system integrations versus browsers and other RTD integrated systems). |
| REQ-117 | Technical Support | Support and Maintenance | Contractor shall provide technical support services to RTD to support integration of existing and future enterprise applications that exchange data with the solution. |
| Testing Requirement ID | Testing Requirement Name | Testing | Description |
| REQ-118 | Contractor Testing | Testing | The Contractor shall perform all testing so as to satisfy the objectives of each testing stage as per the RTD approved test plan. Testing shall include all labor, materials, and support services required to completely test the installed Solution. |
| REQ-119 | Test Failure Tracking | Testing | The Contractor shall maintain a database of and shall track the status of all test failures; errors, defects, or missing functionality. |
| REQ-120 | Test Failure Severity | Testing | All test failures shall be recorded by the Contractor and assigned a Severity rating as follows: |
Severity 1: Required core functionality is substantially not available Severity 2: Functionality is substantially available however one or more subfunctions are not operating as specified or full functionality is available, but performance is not within specifications Severity 3: Minor failure or usability problem for which there is a fix or workaround
| REQ-121 | Test Failure Severity | Testing | RTD shall reserve the right to re‐classify a severity assignment. |
| REQ-122 | Testing and Defects | Testing | Test continuation, suspension or restart shall be as follows: |
1. Severity 1: Applicable test(s) shall be halted and restarted from time zero (0) upon rectification of the Severity 1 test failures.
2. Severity 2: Applicable test(s) shall be suspended and restarted upon rectification of the Severity 2 test failures
3. Severity 3: Testing may continue. Test failure shall be noted in the comments section of the report.
| REQ-123 | Testing and Defects | Testing | All Severity 1 and 2 test failures shall be corrected prior to completion of the stage of testing where they were identified. Test results for that stage shall not be accepted until such time as the Contractor demonstrates that all Severity 1 and 2 test failures have been resolved and tested. |
| REQ-124 | Testing and Defects | Testing | Severity 3 test failures may be carried forward into the next stage of the project and shall be demonstrated to be corrected in the next planned testing stage. |
| REQ-125 | Test Records | Testing | Upon successful completion of any test, the Contractor shall prepare and submit within 10 days, a report summarizing the results with relevant test records appended. All such test reports will be reviewed and approved by RTD prior to acceptance of the test results. |
| REQ-126 | Testing of Changes | Testing | All changes to the solution shall be tested by the contractor before delivering to RTD. |
| REQ-127 | Test/Development Environments | Testing | The Contractor shall provide RTD with separate fully functional Test and Development environments. No development shall occur in the Test environment. |
| REQ-128 | Network Test Results | Testing | The Contractor shall accept RTD’s network test results for network issues. RTD has significant network diagnostic testing capability (e.g. tests for pings, spanning tree, VLAN, routing, buffers, switch restarts, operational status of uplinks, utilization levels, Mesh status, etc.). |
| REQ-129 | System Integration Testing (SIT) | Testing | The Contractor shall install the Solution and demonstrate the integrated operation of all Solution components. The integrated operation of all Solution components will be demonstrated, to the extent possible, in test/development environment before moving to production. The integrated operation of all Solution components shall be demonstrated both in the production and, after failover, to the backup environments. |
| REQ-130 | System Integration Testing (SIT) | Testing | The System Integration Testing shall include time and provisions for RTD staff to conduct independent System integration testing using their own or ad‐hoc script and test cases. Contractor will provide support during these tests. |
| REQ-131 | Performance/Load Testing | Testing | The contractor shall perform load/performance testing simulating high volume to ensure the solution functions properly. Details of this testing shall be provided in the test plan. |
| REQ-132 | System Acceptance Testing (SAT) | Testing | SAT shall be conducted for a minimum thirty (30) days, during which time the Contractor shall measure and report on performance and failures on a weekly basis and RTD shall actively monitor the continued performance and functionality of the complete System under diverse revenue service conditions. |
| REQ-133 | Additional test failures during SAT | Testing | System Acceptance shall be granted once any additional test failures identified during the SAT period have been rectified. This may result in the SAT extending beyond thirty (30) days from its initiation and shall be for as long as is needed for all deficiencies to be resolved. |
| REQ-134 | Final Acceptance | Testing | Final acceptance shall occur after passing SAT and submitting all required documentation to RTD. |
| REQ-135 | Documentation | Documentation | All documentation shall be in English, shall utilize Imperial measurements, and shall be submitted directly to RTD electronically in the following formats, as applicable: |
MS Office formats (DOC, XLS, PPT, VSD) Adobe PDF (searchable) AutoCAD formats (DWG, DWX) Scanned documents consisting of signatures, etc. may be approved for submittal.
| REQ-136 | Documentation (Manuals) | Documentation | The Contractor shall provide written detailed system operation, administration, configuration, architecture, and maintenance manuals to RTD. Manuals shall be complete, accurate, and up-to-date, and shall contain only information that pertains to the system(s). |
| REQ-137 | Documentation | Documentation | Approved documentation shall be a condition of final acceptance, and updated documentation will be required at any time the Contractor provides software upgrades. If the documentation as submitted is found to be unacceptable due to incompleteness or inaccurate information, the documentation shall be returned to the Contractor for corrective action and be resubmitted for acceptance prior to the release of Final Acceptance payment. |
| REQ-138 | Documentation | Documentation | The Contractor shall provide an Interface Control Document (ICD) and Entity Relationship Diagram (ERD) for all interfaces. |
| REQ-139 | Collaboration Tools | Documentation | The Contractor shall use RTD's Microsoft Team Site for a document sharing/repository. |
| REQ-140 | Online Documentation | Documentation | Contractor shall provide online support including FAQs and online help for the Solution. |
Sheet2
File details come from the government source that posted it. Updated .