Exhibit_J_-_TVM_Requirements_Compliance_Matrix.xlsx
XLSX spreadsheet 37 KB Posted
- Solicitation number
- RFP 126FO005
- Issued by
- Denver County, Denver City, Colorado
About this file
This is a Requirements Compliance Matrix for a Ticket Vending Machine (TVM) replacement project by the Regional Transportation District (RTD) in Denver, Colorado. The project involves removal of 185 existing TVMs and installation of 173 new TVMs, including 113 units at existing locations, 54 units along the East Colfax Bus Rapid Transit corridor, one unit at Civic Center Station, five spare units, and an option to purchase six additional units for Denver Union Station Bus Concourse. The compliance matrix outlines 141 functional and non-functional requirements that bidders must address, covering accessibility features, payment technologies, security measures, network connectivity, hardware specifications, training and documentation, testing procedures, and warranty terms. Requirements address ADA compliance with language options in English and Spanish plus Russian, Simplified Chinese, Vietnamese, and Korean; anti-counterfeit measures including secure printing and QR codes; integration with RTD's Account-Based Ticketing system and fare management system; contactless payment readers with 99.99% uptime; remote configurability by RTD authorized users without vendor involvement; and support for multiple payment methods including cash, coin, credit, debit, and mobile wallets.
The matrix specifies comprehensive project management requirements including weekly or bi-weekly progress meetings, monthly status reports, detailed project schedules using Microsoft Project, and site visits with at least two weeks' notice. Design review requirements mandate preliminary and final design review meetings with formal agendas and summaries, along with a demonstration environment for visualization of system features. Training requirements include component-specific instruction on all TVM systems, instructor-led on-site or remote training in the Denver area, and permission to record sessions for future in-agency use. The contractor must provide a Service Level Agreement with response times ranging from one hour for Severity 1 issues to ten working days for Severity 3-4 issues, plus 24/7 support availability. Testing includes System Integration Testing and minimum 30-day System Acceptance Testing with weekly performance reporting. Warranty requirements include eight years or the expected useful life coverage whichever is longer, with parts-only coverage commencing from installation acceptance, plus software and firmware defect corrections at no cost. The proposal notes a 5% Small Business Enterprise (SBE) goal for this contracting opportunity.
View the file
Other files
Show all 22
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
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 | Accessibility and ADA Compliance | Functional | The TVM should be ADA compliant, providing accessibility features such as language options (minimum English and Spanish), audio support, and braille. It should also consider height restrictions for the screen and accommodate wheelchair-bound users. | ||
| REQ-2 | Anti-Counterfeit Measures | Functional | The tickets should include secure ticket printing, holograms, special inks, watermarks, unique barcodes, QR codes, or other methods to prevent forgery and counterfeiting. | ||
| REQ-3 | Checklist and Documentation | Functional | The new system should provide checklists for the periods of preventive maintenance programs, covering cleaning, adjustment, and other relevant tasks. | ||
| REQ-4 | Integration with ABT System | Functional | Collaborate with the Account-Based Ticketing (ABT) system to integrate and streamline operations. | ||
| REQ-5 | Component-specific Training | Functional | Conduct detailed training sessions focusing on each TVM component, such as the cash system, credit card system, bill system, coin collection system, security system, and maintenance procedures. Cover topics like troubleshooting, repair, and preventive maintenance. | ||
| REQ-6 | Configurability | Functional | RTD authorized users shall have the capability to remotely configure TVM screen displays, fares, purchase flows, and workflows without vendor involvement or additional cost. | ||
| REQ-7 | Configurability | Functional | Promotional and informational messaging displayed on TVMs should be remotely configurable without vendor involvement or additional cost. | ||
| REQ-8 | Configurability | Functional | RTD authorized users shall have the capability to remotely configure TVM screen displays and purchase flows without vendor involvement or additional cost. | ||
| REQ-9 | Contactless Readers | Functional | The new system should support contactless payment technologies such as NFC, RFID, Tap-to-pay, QR code or barcode payment, and mobile wallets readers for seamless transactions. | ||
| REQ-10 | Contactless Readers | Technical | Contactless readers must be fully functional and reliable to an uptime of 99.99%. | ||
| REQ-11 | Documentation and Training Materials | Functional | Vendor supplied documentation including training manuals and electronic resources, accessible via a central repository or a wiki. Ensure that the materials reflect the latest updates and changes in the TVMs' operation and maintenance processes. RTD shall retain access to all online training courses and/or materials for the length of the contract. All training materials shall become the property of RTD at the conclusion of training. | ||
| REQ-12 | Fare Management | Functional | TVMs must integrate with RTDs fare management system to accommodate new and future fare structures through configurable fare calculation rules and purchase flows for the life of the contract. | ||
| REQ-13 | Functional Capabilities | Functional | Multiple language options including Russian, Simplified Chinese, Vietnamese, and Korean | ||
| REQ-14 | Integration | Functional | The ability to allow vendor remote access for support and maintenance | ||
| REQ-15 | Integration of TVM Reporting | Functional | Integrate TVM reporting with other systems to gather transaction volume and usage data, enabling efficient monitoring of TVM performance and data-driven decision-making. | ||
| REQ-16 | Local Security Controls | Functional | TVMs must provide for local security controls, including tamper and picking proof locks including alarms, data encryption, access controls, and audit trails to ensure data protection. | ||
| REQ-17 | Data Security | Functional | Must adhere to RTD cybersecurity standards during integrations and transmissions of data from TVMs to RTDs network | ||
| REQ-18 | Multiple Ticket Types in a Single Transaction | Functional | Customers should have the option to select and purchase multiple ticket types in a single transaction, streamlining the ticket purchasing process. | ||
| REQ-19 | Network Connectivity | Functional | TVMs must have ethernet connections for reliable and fast communication. | ||
| REQ-20 | Battery Back Up | Non-functional | Backup battery (UPS) power sources for redundancy | ||
| REQ-21 | Hardware/Software Version | Non-functional | Track hardware/software versions to identify obsolescence risks | ||
| REQ-22 | Payment Options | Functional | The system must support multiple customer payment technologies including but not limited to cash, coin, credit, debit, mobile wallet, contactless payment technologies for seamless transactions that are fully functional. | ||
| REQ-23 | [omitted] | [Omitted] | [Omitted] | ||
| REQ-24 | PIN Verification | Functional | The readers should support PIN chip verification for debit cards and increasingly for credit cards, ensuring secure authentication of the cardholder. | ||
| REQ-25 | Procurement/Replacement Process | Functional | The vendor must be able to provide installations of TVMs | ||
| REQ-26 | Receipt Delivery | Functional | Customers should have the choice to receive receipts via email based on their preference and profile information. | ||
| REQ-27 | Receipt Delivery | Functional | The TVM system should provide a printout of the receipt if required by the customer | ||
| REQ-28 | Reporting | Functional | Track and report on recommended routine service intervals for each TVM | ||
| REQ-29 | Resetting for Next User | Functional | The TVMs should promptly reset after each transaction, within a reasonable time frame (e.g., 7 seconds). Additionally, a cancel button should be available to reset the machine if a user abandons the transaction. | ||
| REQ-30 | Sales Data Analysis | Functional | The system shall enable analysis of ticket vending machine (TVM) sales data to support decision-making related to machine replacement, maintenance prioritization, and service optimization. | ||
| REQ-31 | Machine Utilization Reporting | Functional | The system shall provide utilization metrics (e.g., transactions per day, revenue per machine, downtime frequency) to identify underperforming or underutilized machines. | ||
| REQ-32 | Decommissioning | Functional | The system shall generate analytical reports and visualizations to support decommissioning decisions for low-use or redundant TVMs, based on configurable utilization thresholds. | ||
| REQ-33 | Trend and Forecast Analysis | Functional | The system shall identify sales trends over time to inform future placement, relocation, or investment strategies for TVMs. | ||
| REQ-34 | Data Integration and Access | Functional | The system shall integrate with existing sales and maintenance databases to ensure up-to-date information is available for reporting and analysis. | ||
| REQ-35 | Ticket Printouts | Functional | The current ticket printouts should include all necessary information. Considerations for future improvements include incorporating barcodes or QR codes for compatibility with fare gates. | ||
| REQ-36 | Updates and Version Control | Functional | Maintain an electronic version of the documentation, enabling easy access and distribution of updates. | ||
| REQ-37 | Updates and Version Control | Functional | Vendor must provide software updates and version control | ||
| REQ-38 | Updates and Version Control | Functional | The ability to receive advance notifications and release notes prior to software updates | ||
| REQ-39 | Hardware | Hardware | TVM to have room within the machine to store network appliances (eg. Ruggedcom RST916P or similar) | ||
| REQ-40 | Hardware | Hardware | TVM optimized and hardened and IP 65 rated for outdoor use in all weather conditions | ||
| REQ-41 | Hardware | Hardware | TVM structurally resilient against vandalism, theft, accidents, general destructions | ||
| REQ-42 | IP Rating | Hardware | TVMs to be IP 65 rated | ||
| REQ-43 | Testing and Configuration | Functional | The ability to test functionality and configurations in a sandbox/test environment | ||
| REQ-44 | TVM Basic | Functional | The ability to provide a physically smaller version of a TVM | ||
| REQ-45 | Banking Services | Functional | Must be compatible with RTDs banking services provider, currently Wells Fargo or their successor | ||
| REQ-46 | Design Reviews | Functional | Formal preliminary and final design review meetings shall be conducted by the Contractor. The Contractor will notify RTD of readiness to hold each design review meeting at least two (2), preferably three (3), weeks prior to the meeting. | ||
| REQ-47 | Design Reviews | Functional | Design review meetings will be held to review the Contractor’s Preliminary and Final Design submissions. The design review shall consist of an overall Design Review meeting that provides an overview of the preliminary and final design for the complete Solution (e.g. all hardware, software, wireframes, architecture, security, integrations, etc.). | ||
| REQ-48 | Design Reviews | Functional | The Contractor shall provide the agenda and data package covering information to be addressed in the design review meeting at least five (5) business days prior to the meeting. All information shall be supplied in native format or electronic Portable Document Format (PDF) for electronic review and comment. Design review meeting summaries shall be prepared by the Contractor within five (5) business days of the meeting and submitted to RTD for review and approval. | ||
| REQ-49 | Design Reviews | Functional | The Contractor shall present the design documents and related information in accordance with a previously approved agenda. In the Design Review presentation, the Contractor shall address design approaches, concepts, design details, and interfaces. Following each design review meeting, the Contractor shall revise and re-issue the design documents for RTD review. Following the last preliminary design review meeting a final design review meeting shall be conducted to present the final design documents. | ||
| REQ-50 | Design Review Action List | Functional | The Contractor shall provide a written summary of all design review items arising from the design review meetings and shall indicate proposed actions to resolve outstanding design items within two (2) weeks of the meeting. All issues and proposed resolutions and actions are subject to approval by RTD. | ||
| REQ-51 | Demonstration Environment | Functional | The Contractor shall, during design (i.e. design review meetings) with RTD, make use of a demonstration environment to enable ready visualization of potential Solution design features under discussion. The demonstration environment shall be a configuration from a similar existing installation or test environment and shall include to the extent practical and applicable interconnected hardware and software. The demonstration environment shall also provide access to software configuration settings so that potential changes under discussion can be implemented by the Contractor to demonstrate the impact of the modifications on the system. | ||
| REQ-52 | Kick-off Meeting | Functional | 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-53 | Project Meetings | Functional | RTD Project Manager 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-54 | Project Meeting Agendas | Functional | 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-55 | Meeting Summaries | Functional | 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. | ||
| REQ-56 | Meeting Summaries | Functional | The meeting summaries shall be distributed to all attendees for review within three (3) business days from the end of the meeting. | ||
| REQ-57 | Action Item List | Functional | 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. | ||
| REQ-58 | Issue Tracking systems | Functional | 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-59 | Monthly Status Report | Functional | Contractor shall provide to the RTD PM a status report monthly highlighting key accomplishments, risks, issues, and milestones/deliverables updates. | ||
| REQ-60 | Invoice Documentation | Functional | 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-61 | Project Schedule | Functional | 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. | ||
| REQ-62 | Project Schedule | Functional | 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: | ||
| REQ-63 | Project Schedule Updates | Functional | 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-64 | Site Visits | Functional | 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-65 | Personnel | Functional | All personnel assigned by the Contractor shall display appropriate identification while on RTD property and adhere to all RTD Rules and Regulations. | ||
| REQ-66 | Project Communications | Functional | All email communications from the vendor shall originate from accounts that are owned and managed by the vendor through access management controls. | ||
| REQ-67 | Project Communications | Functional | Within thirty (30) days of Notice to proceed (NTP), the Contractor shall provide a RACI along with Contractor’s escalation procedure, including contact names and information for each level of escalation. | ||
| REQ-68 | Project Communications | Functional | 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-69 | Project Communications | Functional | The Contractor shall coordinate activities with RTD PM regarding affected RTD business units and personnel, and with external individuals and organizations. | ||
| REQ-70 | Subject Matter Experts | Functional | The Contractor shall make all subject matter experts available - when required or requested. | ||
| REQ-71 | Quality Assurance | Functional | The Contractor shall plan, establish, and maintain a Quality Assurance (QA) program. The Contractor’s QA program shall be imposed upon all entities within the Contractor’s organization and on all subcontractors whenever contract work is performed. | ||
| REQ-72 | Quality Assurance | Functional | A QA Program Plan shall be submitted for review within 30 days of Notice to Proceed (NTP). The QA Program Plan shall describe the methods for planning, implementing, and maintaining quality, schedules, and cost. The QA Program Plan shall contain a company policy statement that clearly defines the authority and responsibilities of QA personnel. | ||
| REQ-73 | Training Program and Schedule | Functional | The Contractor shall work with RTD to develop a Training Program and Schedule that describes: | ||
| REQ-74 | Training Instructors | Functional | 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. The training presentations and material shall be in English. RTD shall have the right to direct that an instructor be replaced for cause, at no cost or schedule impact. | ||
| REQ-75 | Training | Functional | The Contractor shall train RTD-designated personnel to install, operate, administrate, and maintain the Contractor-provided solution as required, including solution demonstrations. | ||
| REQ-76 | Training Approval | Functional | 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-77 | Training Location | Functional | The Contractor shall provide instructor-led on-site training in the Denver, Colorado region or remote training as agreed upon with RTD. | ||
| REQ-78 | Recording Training | Functional | The Contractor shall permit RTD to record the training sessions for future in-agency training purposes. | ||
| REQ-79 | Additional Training | Functional | 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-80 | Support Resources | Functional | The Contractor shall provide phone and email support to RTD during [business hours Monday - Friday 8am - 5PM (Mountain Time)] or [24x7] to assist with any issues during the term of the contract | ||
| REQ-81 | Service Level Agreement | Functional | 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 immediately, issue a service ticket number, and offer resolution if possible, within 1 (one) service or working hour. If resolution is not possible, within 2 (two) 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. The solution shall be implemented within 1 working day or less.
- Severity 2 - Severe Impact on System ‐ RTD will call the Contractor Support Line. This first line response will log the call immediately, issue a service ticket number, and offer resolution if possible, within 2 (two) service or working hours. If resolution is not possible, within 4 (four) 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. The solution shall be implemented within 3 working days or less.
- Severity 3 - Minor Impact on System ‐ RTD will call the Contractor Support Line. This first line response will log the call immediately, issue a service ticket number, and offer resolution, if possible, within 1 (one) working day. If resolution is not possible, within 10 (ten) 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. The solution shall be implemented within 7 working days or less.
- Severity 4 - Watch Status ‐ RTD will call the Contractor Support Line any time 24x7x365. This first line response will log the call immediately, issue a service ticket number, and offer resolution if possible, within 1 (one) working day. If resolution is not possible, within 10 (ten) 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-82 | Update Schedule | Functional | Contractor shall provide annual schedule and monthly update reports of upcoming application patches and fixes (e.g. monthly, quarterly, annually) and end-of-life notices. |
| REQ-83 | Release Notes | Functional | Contractor shall include, with release notes, the expected time required for any particular update to complete. (e.g. expected downtime) |
| REQ-84 | Outages | Functional | The Contractor shall proactively (at least 2 weeks in advance) alert RTD to any planned updates and outages to the system. |
| REQ-85 | Support and Maintenance | Functional | Contractor shall provide a method/process for hardware and software updates that ensures all devices have received updates. |
| REQ-86 | Support and Maintenance | Functional | Back-end software must provide a report that identifies software version by device. |
| REQ-87 | Patching/Upgrades | Functional | 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-88 | Patching/Upgrades | Functional | 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-89 | Compatibility with 3rd party software | Functional | 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-90 | Technical Support | Functional | Contractor shall provide technical support services to RTD to support integration of existing and future enterprise applications that exchange data with the solution. |
| REQ-91 | Remote Maintenance | Functional | RTD shall be able to perform remote and on-site maintenance on the devices (Remote master device management tool) |
| REQ-92 | Repair Support | Functional | The Contractor shall supply repair support via RTD sending the broken hardware back to the Contractor for exchange of new equipment as needed. |
| REQ-93 | Firmware/Software Compatibility | Functional | The Contractor shall supply compatible firmware and software versions across the fleet over the life of the contract. |
| REQ-94 | Reliability | Functional | Proposers shall characterize the reliability of the equipment types on either the basis of elapsed time (mean time between failures) or number of events (such as a number of failures per a number of transactions). This is required for TVMs, and preferred for other asset types including software and other system elements other than TVMs and change machines (if applicable). |
| REQ-95 | Test Plan | Functional | The Contractor shall develop test plan(s) and detailed test cases, with acceptance criteria, cooperatively with RTD which demonstrates all requirements have been met. |
| REQ-96 | Test Plan | Functional | The Contractor shall supply, to RTD, a detailed test plan that spells out the types of testing that will be performed, testers, and schedule. |
| REQ-97 | Test Cases | Functional | The test cases shall be mapped to the contract requirements using a traceability matrix listing each requirement proposed to be demonstrated to applicable test case(s). |
| REQ-98 | Test Cases | Functional | Unless otherwise specified, all test cases shall include at a minimum the following: |
| REQ-99 | Test Case Approval | Functional | Test case approval will be based on RTD validation that they will collectively serve to fully demonstrate all requirements. |
| REQ-100 | Test Plan | Functional | Test plan(s) and test cases shall be submitted to RTD a minimum of 30 days prior to the planned start of testing. Testing shall not commence until the test plan(s) and test cases have been approved by RTD. |
| REQ-101 | Contractor Testing | Functional | 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-102 | Test Failure Tracking | Functional | The Contractor shall maintain a database of and shall track the status of all test failures; errors, defects, or missing functionality. |
| REQ-103 | Test Failure Severity | Functional | All test failures shall be recorded by the Contractor and assigned a Severity rating as follows: |
| REQ-104 | Test Failure Severity | Functional | RTD shall reserve the right to re‐classify a severity assignment. |
| REQ-105 | Testing and Defects | Functional | Test continuation, suspension or restart shall be as follows: |
| REQ-106 | Testing and Defects | Functional | 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-107 | Testing and Defects | Functional | 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-108 | Test Records | Functional | 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-109 | Witness during Testing | Functional | RTD or its representatives shall have the right to witness any and all tests. No test shall be considered complete until results are signed off by an authorized RTD representative. |
| REQ-110 | Changes to System | Functional | Significant or major changes to solution shall initiate a restart of Testing Stage, based on RTD's definition of significant or major change. |
| REQ-111 | Testing of Changes | Functional | All changes to the solution shall be tested by the contractor before delivering to RTD. |
| REQ-112 | Readiness Report | Functional | The Contractor shall submit a Readiness Report requesting RTD approval to begin the System Acceptance Testing (SAT) at least five (5) days prior to the planned commencement of SAT. The report shall demonstrate at a minimum that: |
| REQ-113 | Test/Development Environments | Functional | The Contractor shall provide RTD with separate fully functional Test / Development environments. No development shall occur in the Test environment. |
| REQ-114 | Test Hardware | Functional | The Contractor shall provide to RTD, fully configured hardware, to be used for RTD's test environment. |
| REQ-115 | Network Test Results | Functional | 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-116 | System Integration Testing (SIT) | Functional | 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-117 | System Integration Testing (SIT) | Functional | 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-118 | System Acceptance Testing (SAT) | Functional | The SAT shall include a test of the Disaster Recovery Site failover System and procedures. |
| REQ-119 | System Acceptance Testing (SAT) | Functional | 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-120 | Additional test failures during SAT | Functional | 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-121 | Final Acceptance | Functional | Final acceptance shall occur after passing SAT and submitting all required documentation to RTD. |
| REQ-122 | Documentation | Functional | All documentation shall be in English, shall utilize Imperial measurements, and shall be submitted directly to RTD electronically in the following formats, as applicable: |
| REQ-123 | Documentation (Manuals) | Functional | 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) installed. |
| REQ-124 | Documentation | Functional | All pages of the documentation shall carry a title, version and page number and issue date. All manuals shall contain a complete subject index. |
| REQ-125 | Documentation | Functional | Documentation shall require re-issuance if any change or modification is made to the system proposed to be supplied. The Contractor may re-issue individual sheets or portions of the documentation that are affected by the change or modification. Each re-issuance or revision shall carry the same title as the original, with a change in version number and issue date. |
| REQ-126 | Documentation | Functional | Approved documentation shall be a condition of final acceptance, and updated documentation will be required at any time the Contractor provides software or hardware 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-127 | Documentation | Functional | The Contractor shall provide an Interface Control Document (ICD) and Entity Relationship Diagram (ERD) for all interfaces. |
| REQ-128 | Collaboration Tools | Functional | The Contractor shall use RTD's Microsoft Team Site for a document sharing/repository. |
| REQ-129 | System Implementation Plan | Functional | The Contractor shall develop a System Implementation Plan (SIP) no less than 60 days prior to start of system implementation. The SIP describes how the System will be installed, deployed and transitioned into an operational System. The SIP will contain an overview of the System, a brief description of the major tasks involved in the implementation, assumptions, constraints, risks, the overall resources needed to support the implementation effort (e.g., hardware, software, facilities, materials, and personnel), and the cutover plan to transition to the new System with minimal adverse impact to RTD’s operations. The overall sequence and site-specific implementation specifications will also be documented. The SIP must be approved by RTD prior to its implementation. |
| REQ-130 | Online Documentation | Functional | Contractor shall provide online support including FAQs and online help for the Solution. |
| REQ-131 | QR code Functionality | Functional | The system shall be able to print QR codes readable by Fare system validators. Specification to be provided by ABT vendor |
| REQ-132 | Warranty Coverage | Non-Functional | The hardware shall be warranted against defects in materials and workmanship under normal use for the duration of the warranty period specified in the contract. |
| REQ-133 | Replacement of Defective Parts | Non-Functional | If a component is determined to be defective and covered under warranty, the manufacturer shall provide a replacement at no cost to RTD. |
| REQ-134 | Return Material Authorization (RMA) | Non-Functional | An approved RMA number must be obtained to process a warranty claim. |
Field Replaceable Units must be eligible for RMA processing.
Replacement FRUs must be shipped to RTD within two to five business days of RMA approval.
Return mailing labels and packaging, if required, must be provided at no cost to RTD.
| REQ-135 | Warranty Duration | Non-Functional | Parts only coverage shall be included for eight years or the Expected Useful Life of the asset, whichever is longer, beginning on the date of installation acceptance of the entire system. All warranty periods shall commence and expire on the same dates. |
| REQ-136 | Warranty Cost Structure | Non-Functional | The cost of the warranty shall be provided as: |
Cost per year, with options for initial warranty period plus annual renewal options, or
Priced for the entire coverage period.
| REQ-137 | Warranty Exclusions | Non-Functional | All exclusions must be listed in detail in the proposal response. |
| REQ-138 | Software and Firmware Warranty | Non-Functional | If software or firmware fails due to a defect in design, coding, or implementation, and the defect is confirmed by the manufacturer, corrective updates, patches, or replacement versions shall be provided at no cost to RTD. |
| REQ-139 | Software and Firmware Warranty | Non-Functional | The manufacturer shall cover the cost of any backend system updates necessary to restore functionality, provided the updates are part of the originally licensed software included with the hardware purchase. |
| REQ-140 | Software and Firmware Warranty | Non-Functional | If defects require partial hardware replacement of Field Replaceable Units, replacement parts shall be shipped within two business days. |
| REQ-141 | Software and Firmware Warranty | Non-Functional | If defects require full reinstallation, the RMA process shall be initiated, and replacement hardware shall be provided within two business days. The manufacturer shall cover: |
Replacement hardware
Packaging
All shipping costs
Sheet2
File details come from the government source that posted it. Updated .