9-816192-Ex-F-Solar Power Monitoiring-Requirements Traceability Matrix 8 4 2026.xlsx
XLSX spreadsheet 258 KB Posted
- Attached to
- Solar Power Monitoring System
- Solicitation number
- 144759
- Issued by
- Travis County, Austin City, Texas
About this file
This is a Requirements Traceability Matrix (RTM) and Scope of Work document for a Solar Power Monitoring System procurement by CapMetro (Central Texas public transportation agency) in Texas. CapMetro is requesting proposals for a Software as a Service (SaaS) solution to monitor 49 currently equipped solar power systems installed at bus stops throughout the service area, with capability for future expansion. The system must provide remote monitoring, real-time access, web-based dashboards, diagnostic reporting, battery protection monitoring, and performance analytics. Key deliverables include project management documentation, system design and architecture documentation, comprehensive testing across multiple phases (Functional Unit Testing, System Integration Testing, End-to-End Testing, System Acceptance Testing), training programs for system administrators and field maintenance personnel, operations manuals, and post-implementation support. The project phases include Plan, Design, Develop, Test, Deploy/Go Live, and Close, with contractor responsibility for managing the full project lifecycle from Notice to Proceed through final system acceptance and closeout.
The contractor must deliver a complete cloud-based solution with all necessary hardware, software licenses, and services to fully configure and integrate the monitoring system with existing CapMetro infrastructure via Single Sign-On (SSO) authentication. System requirements include 99.99% monthly back-office application availability, 95% uptime with 5% maintenance allowance, 24/7/365 technical support with 15-minute response times for critical issues, and a Mean Time to Resolution of 4 hours for Severity Level 1 incidents. The contractor shall provide comprehensive warranty and maintenance agreements including RMA services, software updates, spare parts inventory, field technician support, predictive maintenance capabilities, and System Level Agreements (SLAs). Additional requirements include compliance with WCAG 2.0 AA accessibility standards, Americans with Disabilities Act (ADA) compliance, Payment Card Industry (PCI) standards, secure encryption protocols, disaster recovery planning with regular testing, and adherence to all federal, state, and local regulatory requirements. The document specifies detailed technical security controls, data protection measures, audit logging, intrusion detection systems, and comprehensive change management and configuration management procedures.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 12-816192-Ex-IT-ConsultantAccess-DisclosureAgrmt.docx | DOCX document | |
| 4-816192-Ex-B-RepsNCerts-LOCAL-Fill.docx | DOCX document | |
| 10b-816192-Ex-G-PPQForm-Fill.doc | DOC document | |
| 6-816192-Ex-C-1-ExceptionsAndAssumptions-Fill.xlsx | XLSX spreadsheet | |
| 3-816192-Ex-A-Pricing-Schedule-Fill.xlsx | XLSX spreadsheet | |
| 00-RFP-816192-SolarPwrMonSys-Cmplt.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
Drop Downs
| Off the Shelf |
| Configuration |
| Enhancement (Not Customization) |
| Modification (Customization) |
| Third Party Solution |
| Third Party Solution with Customization |
| Does Not Meet |
| Approval Functionality |
| Implementer Functionality |
| Mobile Functionality |
| Notification Functionality |
| Reporting Functionality |
| Requestor Functionality |
| System Administration |
| System Integration |
| System Navigation |
| System Security |
Instructions This matrix contains the following Appendices. Some Appendices require a response, while others are for reference purposes to help proposers prepare a response.
1. General Requirements - For each Compliance Term, select "C-Comply," "N-Cannot Comply," or "A-Will Comply with Alternative." If "N" or "A" are selected, comments are required; however, CapMetro strongly recommends that comments be added for each item.
2. Appendix A: Core Requirements RTM - Please provide a response to each item. Additional instructions are provided within the Appendix.
3. Appendix B: Project Phase Requirements - For reference/informational purposes
4. Appendix C: Technical Questions - Please provide a response to each item. Additional instructions are provided within the Appendix.
5. Appendix C2: Technical Questions - Please provide a response to each item. Additional instructions are provided within the Appendix.
6. Appendix D: Integrations - For reference/informational purposes
7. Appendix F: Definitions - For reference/informational purposes
Additional Instructions:
1. The Contractor must deliver a system encompassing all hardware (if needed), software, license, and service requirements, including the delivery of third-party products to make the solution fully functional.
2. The requirements in the Scope of Work and Compliance Matrix are functional in nature and do not encompass all requirements. The Contractor shall determine the technical modifications needed to carry out the intent herein. Vendor shall document and discuss said needs with CapMetro and implement the agreed-upon solution accordingly.
3. The vendor must deliver all Compliance Terms unless it is within a section marked "Optional" that is not exercised by CapMetro or CapMetro agrees to an alternative.
INSTRUCTIONS EXHIBIT F - COMPLIANCE MATRIX AND SCOPE OF WORK
RFP 816192 &P OF &N
Template Definitions CapMetro - Requirement Traceability Matrix (RTM) Definitions
PURPOSE: To define each of the columns in the Requirements Traceability Matrix (Master Requirements Listing tab)
| RTM Column Name | Column Description / Definition |
| Process Columns | |
| Requirements (Req.) ID | The unique identification number for the business requirement. The number ties to the number scheme of the process classification framework levels (Classification framework level descriptions provided in the subsequent columns.) |
| Count | The individual requirement identifier that provides a total requirement count for all process areas. |
| Process Level 0 Name | Identification of the Level 1 process name that represents the highest primary process level for CapMetro (e.g., Level 0 can be defined as System Security, or System Navigation, Approval Functionality, etc.). |
| Business / Technical Requirements | |
| Requirement Details | Detailed text description of the requirement. |
| Source | The source or artifact from which the requirement originates (e.g., leading practice requirements, CapMetro requirement workshop, CapMetro policy / procedure). If known, the specific reference for the regulation or policy that creates the need for this specific requirement will be listed. |
| Requirement (Req.) Priority | The priority level that that has been assigned through the analysis of input by the source, KPMG, and CapMetro Team. The priority level will assist in requirements planning, reporting, and tracking. The prioritization rating definitions that will be assigned are: |
a. Required – required functionality.
b. Key – provides significant benefit to the business. c. Desired – provides important benefit to the business.
d. Optional – would enhance the product and provide benefit.
| Notes / Comments | Any comments regarding the requirement and/or its traceability with the other checkpoints. |
| Vendor Response | Response from vendor selected from the pick list |
| Vendor Notes | Any explanation from the vendor to support the response |
| Implementation / Testing Traceability | |
| System Component(s) | A description of the application system component(s) linked to the functional requirement. |
| Software Module(s) | A description of the application system software module(s) linked to the functional requirement. |
| Test Case Number | The test case number that is linked to the functional requirement. |
| Tested In | The application system module that the functional requirement has been tested in. |
| Implemented In | The application system module that the functional requirement has been implemented in. |
| Verification | A description of the verification document linked to the functional requirement. |
| Additional Notes / Comments | This column should be populated with any additional comments |
TEMPLATE DEFINITIONS EXHIBIT F - COMPLIANCE MATRIX AND SCOPE OF WORK
RFP 816192 &P OF &N
1. General Requirements
| 1.0 | Overview | |||||
| 1.1 | Project Solar Power Monitoring Requirements | |||||
| 1.2 | CapMetro is requesting proposals for product and services to provide software as a service (SAAS), licenses and services to fully configure, integrate, and rollout to CapMetro monitoring of our solar configured bus stops located throughout th CapMetro service area. | |||||
| # | Compliance Term | Comply | Release | Proposer Comments | CapMetro Response | Test # |
| 2.0 | Project Approach - Project Management | |||||
| 2.1 | The Contractor shall provide a robust project management team and project management plan to support the implementation of the Solar Power Monitoring System Requirement. The Contractor's plan for managing the project shall clearly demonstrate an appropriate allocation of project management resources with the ability and experience to ensure that system design and implementation will be coordinated appropriately and managed and completed on schedule and within budget. The Contractor shall provide tools to manage tasks, schedule, risk, change, and the other items listed in this section that are required to manage the project. | C-Comply | ||||
| 2.2 | The Contractor's proposed Project Manager (PM) must be approved by CapMetro, possess a PMP certification with good standing, and have prior experience in the public transportation sector. | |||||
| 2.3 | The Contractor shall comply with all requirements of "Appendix B Project Phase Requirements" which define project management requirements | |||||
| 3.0 | Project Approach - Project Management Plan | |||||
| 3.1 | The Contractor shall submit a comprehensive Project Management Plan (PMP) following Notice to Proceed (NTP) that details at a minimum project organization; master schedule; and how the Contractor will manage project scope, cost, risk, quality, project changes, safety, and other key aspects of the project. | |||||
| 3.2 | The Project Management Plan (PMP) will include but is not limited to the following elements: |
• Organization chart identifying key project personnel and contact information.
• Master schedule, identifying key project milestones and activities in Microsoft Projects format.
• Schedule for all project design and development elements that require CapMetro approval.
• Project meetings and schedule for recurring meetings.
• Methodology to control project schedule, scope, cost, and risk.
• Risk management plan and risk register, including identified project risks and actions required to mitigate them.
• Transition and change management processes and procedures.
• Quality assurance processes and procedures to confirm that the requirements of the contract are being met.
• Subcontractor management and communications.
• Document naming conventions and Action Items and Issues List (AIL) control processes and procedures, including version and traceability controls.
• Change management plan and procedures for all deliverables and subsequent revisions.
• Cost management.
• Communication Plan.
| 4.0 | Project Approach - Project Management: Design Review |
| 4.1 | The Contractor shall provide a robust project management team and project management plan to support the implementation of the Access Request System. The Contractor's plan for managing the project shall clearly demonstrate an appropriate allocation of project management resources with the ability and experience to ensure that system design and implementation will be coordinated appropriately and managed and completed on schedule and within budget. The Contractor shall provide tools to manage tasks, schedule, risk, change, and the other items listed in this section that are required to manage the project. |
| 5.0 | Project Approach - Design and Development |
| 5.1 | The Installation and Transition Plan will describe detailed installation and configuration of all software systems, including the Access Request, interfaces, and web applications, and their respective schedules. |
| 5.2 | The Contractor shall follow a defined quality change control and testing process (e.g. ITIL Service Management) with established baselines, testing and release standards which focus on system availability, confidentiality and integrity of systems and services. |
| 5.3 | The Contractor shall provide a defined change control process and workflow for making configuration or other related changes after Go Live. This includes a process of promotion from Development, to Test, to Production environments. |
| 6.0 | Project Approach - Testing: General Requirements |
| 6.1 | The Contractor shall provide all labor and materials required for system testing, including but not limited to unit testing, performance testing, security testing, system integration and end to end testing. |
| 6.2 | Before starting all formal testing activities that are to be witnessed and approved by CapMetro, the Contractor shall conduct “dry-run” testing to identify and resolve any issues and avoid unexpected results during the formal testing. |
| 6.3 | The Contractor shall provide CapMetro with scripts to test. |
| 6.4 | The Contractor shall provide a methodology for uploading mass amounts of historical and transactional data for the purposes of testing. |
| 6.5 | The Contractor shall provide a testing tool, or set of testing tools, to support automated testing of test scripts as applicable, including documentation and resolution of defects. The contractor shall also create required test scripts for testing with the automated test tool. Automated test tool should be able to test complex test cases, dependencies, integration and link results to feed between test scenarios |
| 7.0 | Project Approach - Testing: Test Documentation |
| 7.1 | The Contractor shall submit a draft Test Plan for CapMetro review and approval during design review and shall submit a final inspection and test plan to be used in connection with all tests described in this specification before the start of any testing. |
| 7.2 | The Test Plan will include a testing timeline, objectives, entrance and exit criteria, and success criteria for functional, system integration, and end to end testing. The Test Plan will also include resource assignments (Contractor and CMTA) and defect resolution processes. |
| 7.3 | Detailed test procedures will include mapping to the design documents and the requirements in the SOW that are related to the test. |
| 8.0 | Project Approach - Testing: FUT (Functional Unit Test) |
| 8.1 | CapMetro shall complete functional tests for the Access Request demonstrating and verifying all functions described in these specifications and design documents, including a review of all user-accessible screens and commands. |
| 8.2 | Successful completion of the development of back-office applications, mobile apps, and website software, and installation of production equipment in CapMetro test facility are prerequisites for the commencement of FUT. |
| 9.0 | Project Approach - Testing: ETE (End to End Testing) |
| 9.1 | The Contractor shall work with CapMetro to develop end to end test scenarios (ETE). The ETE scenarios shall encompass functionality covered in the FUTs, but should also include novel scenarios focused on holistic business processes. The Contractor shall develop scripts to support ETE scenario execution in the Access Request test environment, including data reconciliation and reporting. |
| 9.2 | Successful completion of the development of back-office applications, mobile apps, and website software, and installation of production equipment in CapMetro test facility are prerequisites for the commencement of End to End Testing. |
| 10.0 | Project Approach - Testing: SIT (System Integration Test) |
| 10.1 | For SIT, the test system will be provisioned with test data simulating the system’s operational databases under full operational load. Full operational load will be defined in the SIT test procedure, and approved by CapMetro prior to commencement of SIT. |
| 10.2 | The Contractor shall conduct data transmission testing during SIT to demonstrate, exercise, and verify transaction processing and data uploads and interfaces from all modules and outside systems. Contractor shall confirm proper integrations and interfaces between all systems. |
| 10.3 | SIT will include database accuracy testing, which will demonstrate the accuracy between the AUT (application under test) and the data warehouse in which archived data is stored. The testing should also demonstrate atomicity, consistency, insolation and durability of the database. |
| 10.4 | SIT will include a full system audit and settlement test, which will demonstrate the flow of all financial and procurement transactions through the system with the appropriate reporting, accounting, and calculations demonstrated. |
| 10.5 | With successful completion and approval of SIT, all software and configuration files will be “frozen,” and Contractor will make no changes without CapMetro authorization. |
| 10.6 | The automated failover process will be exercised in multiple failover scenarios during systems integration testing to demonstrate no data loss or significant degradation in system performance. The Disaster Recovery Plan will include regular failover testing after implementation. |
| 11 | Project Approach - Testing: SEC (Security and Access Testing) |
| 11.1 | For SEC, the Contractor shall conduct testing of user access and roles within the Access Request as well as external penetration testing. SEC will leverage defined user IDs and criteria approved by CapMetro. |
| 11.2 | Contractor shall conduct ST to a level sufficient enough to confirm user access to modules, screens, transaction codes, reports, and display/edit rights. |
| 11.3 | The Contractor shall design and execute a test plan to assess the vulnerability of the Access Request system to unauthorized access (internal and external) and system mitigation efforts. |
| 12.0 | Project Approach - Testing: SAT (System Acceptance Test) |
| 12.1 | SAT will be comprised of two periods in which all system components must meet or exceed all system performance requirements. The acceptance test plan will describe in detail how the Contractor will measure and report on each of the performance requirements throughout the SAT. |
| 12.2 | If the performance requirements defined in these specifications are not attained during any one of the 30-day periods, the SAT duration may be extended until all performance requirements are met during an agreed-upon duration. |
| 13.0 | Project Approach - Testing: Final System Acceptance |
| 13.1 | The Contractor shall submit a request for Final System Acceptance upon successful completion of SAT and the determination that all work has been completed per this Scope of Work and final design. |
13.2 CapMetro may grant Final System Acceptance only when:
• The SAT has been successfully completed and approved by CapMetro.
• All system modules, interfaces, and integrations are delivered, installed, and operational.
• All back-office applications and software, including all required reports, are installed and fully functional.
• All requisite contract deliverables have been delivered to CapMetro and accepted.
• The Disaster Recovery Plan has been successfully demonstrated and approved by CapMetro.
• All required training has been provided and accepted by CapMetro.
• All required intellectual property has been delivered to CapMetro or the escrow agent.
• Final resolutions to all identified critical issues (as classified by the Test Failure Log Review Board) are fully implemented and accepted by CapMetro.
CapMetro will issue written certification upon approval of Contractor's request for Final System Acceptance.
| 14.0 | Project Approach - Training |
| 14.1 | Contractor shall provide a comprehensive program to educate and train personnel in all details of the System, enabling them to properly operate, service, and maintain the system and each of its components throughout its useful life. |
| 14.2 | Contractor shall develop and submit for CapMetro review and approval a Training Plan that documents the design of the program for training personnel and each course to be delivered. |
| 14.3 | The course curriculum will include instruction of personnel in at least the following broad categories using a train-the-trainer model: |
• Utilization of all financial and procurement modules
• Utilization of all optional modules exercised by CapMetro, as applicable
• Back-office system administration, configuration, operations and maintenance, reporting, backup, and disaster recovery.
• Reporting, including ad hoc report creation, canned report generation, and report utility
| 14.4 | The Training Plan will include a schedule for delivery of the training courses. The schedule will consider the sequence of training, hours of instruction, system readiness and proximity to startup, trainee availability, and venue for the training. |
| 14.5 | The Contractor shall provide all necessary training materials and equipment for the delivery of each course discussed in the Training Plan. Training documentation will be separate from the operation and maintenance manuals but may reference them. Recordings of the training shall be provided by The Contractor. |
| 15 | Project Approach - Manuals |
| 15.1 | The Contractor shall provide instruction manuals that describe and illustrate in detail how to manage, operate, and maintain the System delivered under the Contractor contract. The manuals will include detailed documentation for all equipment, systems, and software. |
| 15.2 | Disaster recovery procedures will be clearly specified in sufficient detail to consider all possible scenarios. Recovery instructions will describe detailed procedures to be followed in the event that system recovery is needed. Detailed data backup and recovery procedures will be provided. |
| 16 | Project Approach - Data Migration |
| 16.1 | The Contractor shall provide a holistic Data Migration Plan. The plan shall include The Contractor's proposed staffing plan for data migration, migration timelines and processes, data validation approach and timeline, and proposed tools to support the data migration process. |
| 16.2 | Data migration scope shall include historical data, data warehouse integration, data mapping (legacy to future), and data validation (technical and functional). |
| 17 | Project Approach: Demos and Scripted Demos |
| 17.1 | The Contractor shall prepare demonstrations of system functionality (should it be necessary for oral presentations). The demonstrations shall take place in a sandbox or test environments and not consist of a static presentation or screenshots. |
| 18.0 | System Design & Architecture - Common Design Requirements and Guidelines |
| 18.1 | The Contractor shall provide a cloud based Software as a Service (Saas) system that is scalable to meet the growing needs of CapMetro. The Access Request system should be designed such that it can handle future increases in transactional volume and increased service. |
| 18.2 | The Contractor shall provide a cloud based system meeting CapMetro's requirement to accommodate future system upgrades, patches, and fixes that are rolled out centrally by the Access Request software provider. |
| 18.3 | The Contractor shall present solution design documents for all discreet components of the Access Request system for review and approval by CapMetro |
| 18.4 | The Contractor shall develop an application landscape and Access Request system architecture diagrams for review and approval by CapMetro |
| 18.5 | Users should have the ability to have multiple sessions open simultaneously. This includes sessions within the same environment and sessions across environments (Test, QA and Production). |
| 18.6 | In the event that users have multiple sessions open in different environments, the Contractor shall provide a solution (cosmetic) that allows the user to differentiate between sessions and environments. |
| 18.7 | The Contractor shall provide a cloud based system meeting CapMetro's requirement for external interfaces as defined in Appendix D. |
| 18.8 | The Contractor shall design solutions for RICEW items in addition to those noted in Appendix D. |
| 19.0 | System Design and Architecture - Master Data |
| 19.1 | The Contractor shall provide CapMetro with its approach for the creation and maintenance of master data elements in the Access Request system. This includes, but is not limited to: |
1. System Name
2. System roles
3. User information
| 19.2 | The Contractor's approach shall include a process for the creation of master data and the review of the master data and organizational hierarchy of applicable data with CapMetro personnel, this will include a Master Data Life Cycle Management Process. |
| 20.0 | System Design & Architecture - Accessibility and ADA Compliance |
| 20.1 | Contractor shall design the System to be compliant with current accessibility standards, laws, and regulations to ensure that the System meets or exceeds the Americans with Disabilities Act (ADA) and accessibility requirements of federal, Texas State and Austin regional governments. |
Contractor shall ensure compliance of all equipment and system interfaces and create an Accessibility Compliance Plan to document compliance. This plan will be used throughout design and implementation to ascertain that all accessibility and ADA requirements will be met and to track compliance.
20.2 COMPLIES WITH WCAG 2.0 AA ACCESSIBILITY STANDARDS AND MEETS ALL FOUR SUCCESS CRITERIA.:
- All screens are compatible with assistive technologies including screen readers and screen magnification
- Screens make proper use of forms mode, include alt tags on all data collection boxes and image fields, and metadata read back is strictly limited.
- Properly labelled images and proper use of alt tags is required.
- The ability to navigate pages, utilize functionality and traverse layouts without a mouse is required.
- Users of assistive technology shall have ways to skip redundant navigation.
- Correct headings and labelling structures for pages, forms and data tables.
- Readable content with sufficient contrast ratios and font sizing.
- Contractor shall provide information about user testing with people with disabilities and the results of such testing.
- Software solution shall be compatible will all applicable standards and/regulations regarding accessible information technology resources and (IRIT). In cases where there is conflict between standards the most stringent standard shall be applicable.
| 21.0 | System Design & Architecture - Code and Regulation Compliance |
| 21.1 | Contractor shall design the System to be compliant with relevant standards, laws, and regulations to ensure that the System: |
• Presents no safety hazards for customers and CapMetro employees.
• Will withstand the rigors of the environments in which the equipment will be installed, and the public use to which it will be subjected.
• Provides for the secure storage and transmittal of data.
• Is designed using state-of-the-art methods to maximize quality.
• Satisfies federal, state, and other requirements for ergonomics and usability.
Applicable codes, laws, ordinances, statutes, standards, rules, and regulations include, but are not be limited to the list below (in 3.1.4-2). The latest revisions in effect at the time of Final System Acceptance will apply.
21.2 • Americans with Disabilities Act (ADA)
• Americans with Disabilities Act Accessibility Guidelines (ADAAG)
• Advanced Encryption Standard
• ANSI X9.24, Financial Services Retail Key Management
• European Norm EN55022, Emissions standards for CE marking
• European Norm EN55024, Immunity standards for CE marking
• FCC Part 15 Class B – Radio Frequency Devices
• FIPS 140-2
• IEEE 802.11 a/b/g/n standard for wireless data communications
• IEEE 802.11 i standard for wireless data network security
• IEEE 802.11-2016
• International Electrotechnical Commission Standard 529 (IEC529)
• ISO/IEC 7810, Identification Cards – Physical Characteristics
• ISO 9001
• ISO/IEC‑8583 – Financial transaction card originated messages
• ISO/IEC 14443 Parts 1 through 4 – Contactless Smart Card Standard
• ISO/IEC 18092 / ECMA-340, Near Field Communication Interface and Protocol-1
• ISO/IEC 21481 / ECMA-352, Near Field Communication Interface and Protocol-2
• National Electrical Code (NFPA 70)
• National Electrical Manufacturers Association Publication 250-2003
• National Electrical Safety Code (ANSI C2)
• National Fire Protection Association (NFPA) 130
• NCITS 322-2002, American National Standard for Information Technology – Card Durability Test Methods
• Occupational Safety and Health Administration (OSHA)
• Payment Card Industry Data Security Standards (PCI-DSS)
• Payment Card Industry Payment Application Data Security Standards (PA-DSS)
• Society of Automotive Engineers SAE J1113-13 Electrostatic Discharge
• Society of Automotive Engineers SAE J1455 Vibration and Shock
• UL Standard 60950, “Information Technology Equipment – Safety”
• World Wide Web Consortium, Mobile Web Application Best Practices
• Web Content Accessibility Guidelines WCAG 2.0
| 21.3 | In the case of conflict between the provisions of codes, laws, ordinances, statutes, standards, rules, and regulations, the more stringent requirement will apply. |
| 22.0 | System Design & Architecture - Information Security |
| 22.1 | Contractor develop a plan for the processes that will be used to resume operations in the event of a data loss due to a natural disaster or other emergency situation that puts operations at risk. The plan must describe how mission-critical functions will be resumed and how longer-term challenges created by an unexpected loss will be addressed. The Disaster Recovery (DR) plan will conform to the required service level agreement and be consistent with the Business Continuity Plan and recovery time capabilities that will be provided by CapMetro. |
| 22.2 | Contractor shall propose a physical and logical architecture (e.g. virtualized servers, spare load balancers, etc.) that meets all redundancy capabilities for CapMetro review and approval at design review. |
| 22.3 | The System will be designed to include the appropriate elements and processes to manage, monitor, and quickly address security issues, consistent with the expectations outlined above, to support the operation of CapMetro's Information Security Management System (ISMS). |
| 22.4 | Contractor shall prioritize identified application vulnerability/bug fixes. Security fixes must have higher priority than product enhancements. |
| 22.5 | Key Management - Policies and procedures shall be established, and supporting business processes and technical measures implemented, for the use of encryption protocols for protection of sensitive data in storage and data in transmission as per applicable legal, statutory, and regulatory compliance obligations. |
| 22.6 | Contractor shall provide secure coding training for developers. Provide CapMetro with a description of the Contractor training program for developers, specifically around secure code development practices |
| 22.7 | Code review - Contractor shall provide an overview of their software development lifecycle showing how security is a part of the lifecycle. Specify security tests, how you determine if your code is vulnerable to the common threats facing applications today, such as cross-site scripting or SQL injection, in your quality assurance testing phase. Describe how you track security flaws and flaw resolution. |
| 22.8 | Application security testing – Contractor shall provide an overview of their application testing including annual pen testing, testing by 3rd party, testing by security professional services, and testing that covers the common vulnerabilities as described by OWASP Top 10. Describe the process for vulnerabilities identified and remediations. |
| 23.0 | System Design & Architecture - System Integration Services and Interfaces |
| 23.1 | Appendix D of this Scope and Compliance Matrix provides a high level overview of desired integrations for the Access Request system. The Contractor shall design a system to allow for multiple internal and external interfaces, including, but not limited to those described in Appendix D. |
| 23.2 | In addition to those defined in Appendix D, CapMetro desires and expects the new Access Request system to provide enhanced functionality. As a result, it is expected that the Contractor's system design will allow for additional interfaces and integrations not defined in Appendix D. |
| 24 | Operations and Maintenance Services - Performance Measurement |
| 24.1 | Update the Warranty and Maintenance Agreement with the following components: |
back-office availability will be calculated based on the total out of service time for the associated system:
Back-office application availability = 1 - (out of service time / total operating time)
Total Operating Time is defined as the number of minutes in a day (1440) multiplied by the number of days in the month of measurement, while Out of Service Time is defined as all time during which the System is not in a fully operational state, and includes all time necessary to respond and repair to issues. Scheduled maintenance time is excluded from the calculation.
The availability requirement for each System back-office application is as follows: Application availability must meet or exceed 99.99% each calendar month
24.2 Back-office accuracy shall be based on the number of incidents where a device or Back-office generated transaction is recorded incorrectly within the associated system. Performance will only be measured for those applications for which Contractor is responsible. The accuracy requirements for the System Back-office applications are as follows:
Financial Management application: No more than 2 incidents of inaccurate reporting per calendar month.
| 25 | System Support |
| 25.1 | Provide Post Go Live Support for CMTA staff by phone and email for the software system components. |
Contractor agrees that onsite field engineerings support and onsite prescence may be required by CapMetro at any time during the term of the contract.
24x7x365 - Tech support within 15 minutes of contact
Severity Level 1 - One or more CapMetro department's ability to perform mission critical business functions is in jeopardy because the system is not available. All Severity Level 1 issues will be responded to within 15 minutes of contact and a Mean Time to Resolution (MTTR) of 4 hours or less. These outages will be escalated to the contractor's Account Manager if issues are not resolved within 4 hours, the Chief Techincal Office if not resolved within 8 hours, and the President/CEO if not resolved within 12 hours of down time.
Severity Level 2 - One or more CapMetro department's ability to perform mission critical business functions is in jeopardy because the system is not available, but a workaround can be established within a reasonable time. All Severity Level 2 issues will be responded to within 15 minutes and a Mean Time to Resolution (MTTR) of 8 hours or less. These outages will be escalated to the contractor's Account Manager if issues are not resolved within 8 hours, the Chief Techincal Officer if not resolved within 16 hours, and the President/CEO if not resolved within 24 hours of down time.
GENERAL REQUIREMENTS EXHIBIT F - COMPLIANCE MATRIX AND SCOPE OF WORK
RFP 816192 &P OF &N
2. Appendix A - Core Reqs. RTM
| Item | Compliance Term | Proposer Questions | Cap Metro Response | Comply | Contractor Comments | Cap Metro Response | Test # |
| Compliance Term | Proposer Response | Cap Metro Response | |||||
| Overview | |||||||
| 1.0 | OverView | ||||||
| 1.1 | Introduction. CapMetro is requesting proposals for product and services to provide software as a service (SAAS), licenses and services to fully configure, integrate, and rollout to CapMetro monitoring of our solar configured bus stops located CapMetro service area. |
CapMetro connects people, jobs and communities by providing Central Texans with safe, high-quality and sustainable transportation alternatives. The agency provides 30 million rides annually on its buses, trains, paratransit and vanpool vehicles and serves a population of more than 1.2 million in its 543-square-mile service area. The region’s transportation leader, CapMetro has invested in transit services like its High-Frequency Network, which move more people, more reliably, as well as its innovative on-demand service Pickup. CapMetro is committed to increasing regional mobility and, through Project Connect, will transform how people travel throughout Central Texas. Visit capmetro.org for more information.
The currently equipped bus stops (49 total) have installed a solar power system to provide lighting and infomation signage at stop locations.
1.2 Solar Power at CapMetro Bus Stops Vision. CapMetro seeks to establish remote monitoring of the Solar Power systems currently installed at 49 locations and to be prepared for expansion. The Solar Monitoring System (Monitoring System) provided as a demo proved valuable in providing operational data to show impact in various weather conditions. This knowledge provides design information that may be needed for upgrades and expansion. Data also provided value where power could be sent back to the grid, lowering CapMetro operating costs.
The goal is to continue to support the existing system that is cost-effective to maintain following prime objectives - Full system monitoring that includes:
•Login access via SSO •Ability to access current hardware without modification to existing systems.
• Diagnostic trends to improve current and future installations
• Analytics to establish performance •System Health •Load Impact from powered systems, lights, monitors...
• Remote access to individual power stations •Automated controls to monitor and manage battery life to ensure continuous operation
| 1.3 | Provide battery protection. Continuous Li battery recharging can create dangerous conditions. The monitor system must be able to detect dangerous conditions. Report dangerous conditions to the support teams. Disable battery recharge when conditions could lead to items such as a potential fire. |
| 1.4 | Monitoring Dashboard: The monitoring system must provide a configurable dashboard allowing the user to configure specific monitoring, for instance: 1) Single Station monitoring 2) Rotating station monitoring. 3) Specific conditions, i.e., recharge rate, battery temperature, battery charge state, battery charge, solar recharge state, and solar recharge percent power. |
| System Analytics: |
Provide KPIs: system availability (% of period in normal operation), average daily solar vs. load ratio, BPM event frequency and recovery time, and overall health classification.
| 2.0 | Solar Solution - Minimum Requirements: | |
| 2.1 | Integrate access with CapMetro Users via SSO - per user base | |
| 2.2 | Provide managed/secure remote server with web-based access for application and storage | |
| 2.3 | Complete access security review with CapMetro data security team | |
| 2.4 | Provide 24/7/365 realtime access to all Solar equiped location | |
| 2.5 | SLA operation 95% uptime, provided 5% is for maintenance | |
| 2.6 | Maintain system patches, provide bug fixes. 7 day advanced notice upon discovery of requirement. 24 hour notification for any security notifications | |
| 2.7 | Provide system operation and maintenance training | |
| 3.0 | Management Reporting - Minimum requirements: | |
| 3.1 | Provide Technical performance report. Include daily solar vs. load charts and state-of-charge time-series graphs. | |
| 3.2 | Executive Summary Report - Include system availability, solar generation, and solar coverage metrics | |
| 3.3 | Reporting Metric: | |
| • | System availability (% of reporting period in normal operation) | |
| • | Total solar energy generated (Wh / kWh per day and per period) | |
| • | Total energy consumed by shelter loads (Wh / kWh per day and per period) | |
| • | Average daily solar generation vs. average daily load consumption (ratio) | |
| • | Battery state of charge over time (% with timestamped data points) | |
| • | Battery current (amps, time-series) | |
| • | Battery Protection Mode events — entry timestamp, recovery timestamp, recovery duration | |
| • | Overall health classification per stop | |
| • | Last data point timestamp (connectivity verification) | |
| 4.0 | Equipment Maintenance - Minimum Requirements: | |
| 4.1 | Designed so that field maintenance and repairs can be |
accomplished by a single technician under regular circumstances.
4.2 Generate error logs and reports that will facilitate predictive maintenance; rapid and accurate root cause analysis for efficient resolution; logs shall be available remotely, through the backend, and exportable to PDF, CSV and Excel. At a minimum, error logs shall contain error number, date, time, severity code, error description, unique Solar System identifier, location
| 4.3 | Easily accessible on-off switch within the Solar system enclosure |
| 4.4 | Predictive and preventative maintenance plan and automated |
notifications via email for the Solar solution; remote monitoring shall include "condition based monitoring" of equipment such as internal temperature, amp draw, and other parameters that can be used to determine when maintenance is needed; notifications shall be configurable so that various alerts can be sent to specific individuals
5.0 Training - Minimum Requirements; in the Comment column
indicate for each training the areas to be covered:
| 5.1 | System Administrator: administering the Solar Monitoring system |
| 5.2 | Field Maintenance and Servicing: operation, troubleshooting, |
maintenance, repair, component change-out, and scheduled maintenance of Solar Monitoring system and hardware
| 6.0 | Warranty & Support - Minimum Requirements: |
| 6.1 | A comprehensive inspection, RMA, repair and maintenance |
plan and processes to include recommended spare parts inventory, 24x7x365 phone, email and incident management response, including all time necessary for the support of software, solar equipment for all stations, and test units including:
•Repair Services (beyond RMA) •Software Updates •Test Use Cases •Test Environment •Documentation •On-Site and Field Support as required
6.2 Parts must be readily available with minimal lead times; in the Comments section describe the parts availability and maximum lead times to receive.
6.3 Contractor shall replace any part that becomes obsolete
during the life with one that functions at an equivalent level and maintains parts availability and maximum lead time guarantee
6.4 Provide Service Level Agreement (SLA) to include incident priority, escalation process, hourly rates for additional services (e.g. future training)
7.0 Other Provisions: Contractual or IT Security Provisions of Cap Metro.
| 7.1 | N/A |
| 8.0 | Warranty & Support - Option One: Contractor provides field |
technician(s) and all support to meet the SLAs and provisions in the WMA.
8.1 Contractor will provide the requirements of Cap Metro
providing field technician(s) and first-line software support (perform diagnostics and troubleshooting) to include recommendation of number of full-time equivalent employees (FTE) to support. Describe fully in the Comments column.
8.2 Cap Metro will provide field technician(s) to perform
preventative maintenance and Return Merchandise Authorization (RMA) repairs (replacing components)
8.3 Cap Metro will investigate presenting software issues and submit tickets to Contractor that Contractor shall resolve
APPENDIX A - CORE REQUIREMENTS EXHIBIT F - COMPLIANCE MATRIX AND SCOPE OF WORK
RFP 816192 &P OF &N
Feedback On Reqs Name of Reviewer Date of Review Process Level 0
| Name | Requirements to be Added/Changed/Removed | Requirements Details | Notes | |||
| Charlie Jackson | 4/27/21 | Make sure it conforms to ITIl Identity and Access Management | Related to row 3 | |||
| Charlie Jackson | 4/27/21 | Approval Functionality | Add | Identity Management - proof that Identity has been verified | This is done through AD (not added) | |
| Charlie Jackson | 4/27/21 | Approval Functionality | Add | Access Levels - proper levels of access based on system roles | This is covered in RF12 (not added) | |
| 4/27/21 | System Security | Add | Requests from Outside of capmetro domain: Manage security and access for 3rd-parties | Added as SS5 | ||
| CWatkins | 4/27/21 | System Navigation | Add | Dependencies. i.e. Accessing Trapeze requires an AD account and appropriate group memberships. The UI should guide a requestor through these. Many new hires are made to put in thier own requests so it should be geared towards a day-1 employee. | Inital AD access would be required for the Requestor to submit any additional access requests for themselves. (not added) | |
| CWatkins | 4/27/21 | System Administration | Add | Audit support. | This is covered in RF1 (not added) | |
| Dottie Watkins | 4/28/21 | Approval Functionality | Change | AF4 should be to require access on a mobile device, not mobile app. Ideally, a standalone app would not be required to approve something. | Updated the requirement to reflect mobile device | |
| Kris Turner | 4/29/21 | Add | Display approval date to requestor | Should be done though a notification email. (not added) | ||
| Thomas Lakin | 5/4/21 | Requestor Functionality | Add | When accounts are requested to be created: All necessary account information (email address, windows login ID, etc.) needs to be provided PRIOR to the account request being submitted. We currently must wait for HR or some other system before we finish some requests. This often creates a back and forth between the requestor and the implementor and shows the ticket sitting in the queue as Late when it should never have been entered in the first place. | Required fields are suggested in RF7 | |
| Thomas Lakin | 5/4/21 | Requestor Functionality | Add | When accounts are requested to be deleted: We currently have managers that have no idea what accounts their |
staff have, so when they terminate them, they just shotgun a request to have every application removed even if the person
| never had one in the first place. This wastes the other people’s time searching for nonexistent accounts to remove. | The workflow in the new system should know what systems the user has assigned to them based on their username (profile). This is covered in RF12. | ||||
| Thomas Lakin | 5/4/21 | Requestor Functionality | Add | When an employee leaves one position or company and moves to another within the agency: The accounts need to be |
processed in the correct order. We often receive the new account requests before the old ones which causes confusion
| when the requests to terminate are entered after the new ones have already been created. | Added to RF14 | |||||
| Rich Kaplan | 5/4/21 | Requestor Functionality | Add | Allow for a description of what each role group for a system being requested is, if the system owner provides that, so that the requestor of the account access knows what kind of access the role group being requested gives. | Added to RF15 | |
| Terry Follmer | 5/4/21 | Requestor Functionality | Add | Ability to make requests to add/modify groups of individuals from a list or group instead of having to open up a separate ticket for each individual. For example, we had 19 UT Audit Interns this semester and we had to open up a separate ticket for each person rather than attaching a list with necessary information. | This is covered in RF13. A template that can be used to clone a request. We would still need a ticket for each individual, but this would still be easier than filling out the entire form each time. | |
| Steven Salinas | 5/4/21 | Requestor Functionality | Add | The accounts requests should be profile based so that the requestor should not have to remember or guess what access is needed. E.g. "Rail Dispatch" profile, when chosen, would automatically request any applications they would need. | This is covered in RF12 | |
| Jyothi | 5/4/21 | Implementer Functionality | Add | Need the windows username for the requestee. This needs to be provided for updates. For new requests, this is a pre requisite for implementors of other applications | Added to IF4 |
3.Appendix B - Proj. Phase Req.
| Project Phase Tasks and Deliverables. Contractor shall perform the following phase tasks and provide the associated deliverables required to deploy all hardware, software, updates and configurations resulting in a fully functional and tested system. Contractor shall obtain CapMetro review of all deliverables and make changes and updates to deliverables per CapMetro review as needed. | |
| 1.0 | Plan. Meet with CapMetro project manager and business area stakeholders for project planning, including review of proposed schedule, roles and responsibilities, as well as conduct a complete review of functionality to be delivered, and other project activities. Plan Deliverables from Contractor: |
1. Project organization chart
2. Project schedule and Project Management Plan - (draft)
3. Action Items and Issues log (AIL)
4. Project Decisions Log
5. Project Review Documents (PRDs) for project decisions
6. Initial Risk Register
7. System Implementation Plan (draft)
8. Scope and Compliance Matrix Review and Update
2.0 Design. Contractor's configuration and implementation approach based on CapMetro's previously gathered requirements. This phase will determine how the system will be installed, product wireframe presentation to the customer, and how it will be managed in the back end. Contractor will work with CapMetro to develop materials that will provide a basis to help instruct CapMetro stakeholders in the easiest and most efficient way to use the system to their utmost advantage. Design Deliverables:
. 1. Configuration Management Document (“CMD” - Draft)
2. Solution Design Documents / MVP Lists (If Hybrid Agile Approach)
3. Application Landscape Design Document
4. Integration Design Plan
5. System Implementation Plan (Final) / Sprint Plan (If Hybrid Agile Approach)
6. Data Migration Plan (Draft)
7. Disaster Recovery Plan (Draft)
8. Quality Assurance Plan (Draft)
9. Risk Management Plan (Final)
10. Data dictionary and Entity Relationship Diagram (ERD)
11. Project Schedule (Baseline) with Resource Loading
12. Network architecture diagram (Draft)
13. Perform Preliminary Design Review (PDR) Design and System Implementation Plan with Stakeholders
14. Create Final Design based on review and perform Final Design Review (FDR)
15. Review and Acceptance of Final Design and Project Management Plan
16. Scope and Compliance Matrix Review and Update
3.0 Develop. Development, configuration and installation of the solution and integration as well as installation within a development and a test environment so configuration and testing of the required functionality can be started. This task will include setting the initial configuration values by Contractor so they can be tested and changed if needed. During this phase, the rollout of the system must be worked on to include training all IT and Operational staff who will use or have on-going support roles. Develop Deliverables:
1. Quality Assurance Plan Including QA/QC Checklist (Final)
2. Development of modules, application and interfaces
3. Develop and Design Review Sessions per Sprint (If Hybrid Agile)
4. Retrospective sessions on prior development (If Hybrid Agile)
5. Test Environment Installation that provides CapMetro full access throughout the project and the life of the system
6. Supporting Infrastructure Implemented as applicable
7. Test Procedure/Plan including test Scripts, use cases, acceptance test criteria demonstrating each Compliance Matrix term is developed and meets requirement (Draft)
8. Update Compliance Matrix with Test Number(s)
9. High-level Training of CapMetro Staff to Prepare for Test Phase
10. Contractor Warranty and Maintenance Plan Review
11. Review and Feedback of CapMetro Support Responsibility Matrix
12. Role-based, On-site Training Plan for all User Types (Draft):
•Training schedule and course outlines for review a minimum of three weeks prior to the scheduled classes •Separate training sessions based on functional and technical area •Provide all materials necessary to train participants (CapMetro will provide space and laptops) •Schedule the training staff to be on site timely to ensure equipment, materials, student accounts and classroom are fully ready for when class begins •Arrange for an instructor(s) with thorough knowledge of the material covered in the course(s) and the ability to effectively lead the knowledge transfer •Provide customized training manuals specific to CapMetro's environment in Microsoft Word and PDF. Contractor shall provide the agreed-to number of hard copies
4.0 Test. Contractor shall develop and implement a comprehensive program to test all components and applications that comprise the integrated Contractor ERP solution. Testing is to be performed in five distinct and separate phases:
1. Functional Unit Test (FUT)
2. System Integration Test (SIT)
3. End to End Test (EET)
4. Pilot Test (Day in the Life)
5. System Acceptance Test (SAT) The testing phase shall not be deemed completed until all functional requirements have been fully tested and approved by CapMetro. Contractor shall develop an ERP Test Plan that includes the number and range of tests, detailed schedule indicating the sequence of each test, and when and where each test will take place. Contractor shall not perform any test until the corresponding test plan and procedures have been approved by CapMetro. Contractor shall develop Test Procedure documents with test scripts, all anticipated use cases and acceptance criteria for review and approval by CapMetro for each phase of testing. Test deliverables:
1. Test Plan (including automated testing processes)
2. Test Procedures (including automated testing processes)
3. System Acceptance Test Plan and Execution
4. Execution of FUT, SIT, EET, Day in the Life and System Acceptance Testing
5. Security Penetration Test (performed as part of SAT)
6. Disaster Recovery Test - End-to-End
7. Volume and Stress…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .