JTA Integrated Mobility Application Friday August 16, 2019 at 2:00 PM

Home , Transportation authority

REQUEST FOR INFORMATION FOR:

SUBMISSION DEADLINE:

RFI #: JACKSONVILLE TRANSPORTATION AUTHORITY a121 W. Forsyth Street., Suite 200 • Jacksonville, Florida 32202

Page 1 of 24 JACKSONVILLE TRANSPORTATION AUTHORITY

REQUEST FOR INFORMATION (RFI) FOR

JTA INTEGRATED MOBILITY APPLICATION

RESPONSE SUBMISSION DEADLINE:

BY 2:00 P.M. (EST), FRIDAY, AUGUST 16, 2019

RFI NUMBER: I-19-007

Jacksonville Transportation Authority 121 West Forsyth Street, Suite 200 Jacksonville, FL 32202

JTA RFI No. I-19-007

JACKSONVILLE TRANSPORTATION AUTHORITY

REQUEST FOR INFORMATION No. I-19-007

SUBJECT: JTA INTEGRATED MOBILITY APPLICATION

RESPONSE DEADLINE: AUGUST 16, 2019, 2:00 P.M. (EST)

This Request for Information (RFI) for JTA Integrated Mobility Application will be received by the Jacksonville Transportation Authority ("Authority" or "JTA"), until the above-stated response deadline at the following location:

Jacksonville Transportation Authority Customer Service Desk, Hogan Street Entrance 121 West Forsyth Street Jacksonville, FL 32202

The complete RFI package will be available July 29, 2019 and can be obtained in person at our Customer Center or by visiting https://procurement.jtafla.com.

CONTACT INFORMATION - All questions or concerns regarding this RFI must be submitted by e-mail to JTA Procurement at [email protected].

RESPONSE DELIVERY - Responses must be submitted in an opaque sealed envelope and properly labeled with the name and number of the Solicitation. Responses must be submitted by the due date, at the location identified in the Notice (or as amended in an Addendum). The sealed envelope must contain one (1) original, five (5) copies, and one (1) electronic copy of the entire submitted response. Only promotional or advertising information relevant to the solicitation topic should be included in your response. Please limit response to a cover letter plus attachments with a maximum length of twenty (20) pages. Facsimile and electronic transmissions will not be accepted. Late responses will not be opened. Due to the lack of control over the standard postal delivery service, many companies hand-deliver or use a private delivery service to ensure delivery by the 2:00 P.M. deadline. The Authority is not responsible for the failure of the postal service or private delivery service to locate and deliver the Response in a timely manner. The Authority is the official timekeeper and the Authority's determination of the time shall be deemed correct and final.

Page 2 of 4

JTA RFI No. I-19-007

I. Introduction and Purpose

II. Statement of Need

The proposed solution should be able to encourage and assist in the following:

. Combine functionality of existing JTA apps, . Introduce new functionality to our customers, . Enhance customer experience of JTA transportation services, . Make the functionality available to Regional Partners.

The attached document entitled JTA Integrated Mobility Application Business Requirements (Attachment A) describes the business requirements for a future IMA. It is intended to inform decisions regarding the development of IMA and future RFIs and RFPs for that purpose. Broad input within JTA was solicited to develop the business requirements.

III. Information Requested

Interested Suppliers are encouraged to submit a brief letter of interest addressing the following:

• Please provide a general overview of your current solution and how it addresses some or all of the business requirements. • Please provide an explanation of if, and how you would address any requirements shortcomings. • Please highlight any additional functionality of your platform that would be of use to JTA but was not described in the business requirements document. • Please provide details on how your organization would build and ensure the various system integrations required, including relevant experience, case studies or like examples. • Explain what type of consultation services your organization can provide along with any industry experience you have that can assist the Authority evaluate best business practices. • Are there any limitations to the amount of users that can utilize your product? • Describe if any associated training is required and how your organization typically plans and manages this. Explain any programs for end-users and/or support staff and administrators training you may have. • Describe your feature/upgrade roadmap for the next year, and the typical upgrade process.

Page 3 of 4

JTA RFI No. I-19-007

• Specify hours of conducting business and identify rate of response for customer service support. • What type of devices are required for your solution option and does your organization provide options to obtain them through procurement of your product? • Please include in your response the following information: . Company Name . Tax ID Number . Business Address . Telephone Number . Email Address

IV. Demonstration Determination

As a part of this process, the JTA reserves the right to request product demonstrations or proof-of-concepts for RFI responses that have been determined to address and meet the requirements as set forth in Exhibit A and the Statement of Need and Information Requested sections above.

V. Request for Information Process

After review of the RFI responses and assessment of the marketplace, the JTA may choose to issue a Request for Proposal (RFP) or other appropriate solicitation process. Participation in the RFI process is not a prerequisite for any subsequent competitive procurement, although the results of this RFI may be used to build and refine the Scope of Specification for this product.

Page 4 of 4

JACKSONVILLE TRANSPORTATION AUTHORITY

JTA Integrated Mobility Application Business Requirements

Version: 1.5 Last Updated: 5/7/2019 Authors: Kevin Salzer, Paul Tiseo

JTA INTEGRATED MOBILITY APPLICATION BUSINESS REQUIREMENTS 10/16/2018

Table of Contents

INTRODUCTION ...... 3 STATE OF THE INDUSTRY ...... 3 EXISTING ASSETS/RESOURCES ...... 4 PROCESS AND METHODOLOGY ...... 5

STEP 1: IDENTIFY SUBJECT MATTER AREAS (SMAS) ...... 5 STEP 2: IDENTIFY SUBJECT MATTER EXPERTS (SMES) ...... 5 STEP 3. INTERVIEW SMES...... 6 BUSINESS REQUIREMENTS ...... 6 FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS ...... 9

OVERALL PLATFORM DESCRIPTION ...... 9 REQUIREMENTS LIST ...... 9 RECOMMENDATIONS ...... 18

JTA INTEGRATED MOBILITY APPLICATION BUSINESS REQUIREMENTS 10/16/2018

INTRODUCTION

JTA has recognized the increasing usage of smartphone technology by its customers and the need for more integrated functionality of JTA existing applications. For these reasons, JTA is pursuing an Integrated Mobility Application (IMA). IMA is intended to:  Combine functionality of existing JTA apps  Introduce new functionality to our customers  Enhance customer experience of JTA transportation services  Make the functionality available to regional partners This document describes the business requirements for a future IMA. It is intended to inform decisions regarding the development of IMA and future RFIs and RFPs for that purpose. Broad input within JTA was solicited to develop the business requirements.

STATE OF THE INDUSTRY

The Mobility-as-a-Service (MaaS) space is an emerging market that addresses the needs of riders from a holistic perspective of one-stop trip management. The concept breaks down barriers between modes of transport, operators, ticketing and payments systems and puts it all into one service, providing convenient and seamless journeys for passengers. Given its state of infancy, vendor selection is generally sparse and inexperienced. The following vendors, listed alphabetically, provide offerings that overlap each other in the mobility space. The list is not meant to be all- inclusive, but informative as to some of the leaders in the space.  Cambridge Systematics (CS): CS is a custom software developer that has experience. They are the vendor that has developed and maintains JTA’s TransPortal application (see Existing Assets).  Cubic: Well-known at JTA for the NextBus transit management platform, Cubic is a custom software development shop with deep experience in building solutions.  DoubleMap: DoubleMap offers a mobile-first platform that provides various multi-modal trip planning and payment functions.  Masabi: Masabi is mobile payments company specialized in transit ticketing and payments. Masabi provides multiple parts of the ticketing ecosystem including hardware readers, analytics back-office applications and white-label app and SDK for retail partners. Masabi products are in use in various areas in the US and Europe.  Transit: Montreal-based mobility application developer with MBTA, COTA and Toronto transit agencies as notable clients.  Moovel: Moovel is a child company of Daimler-Chrysler with some traction is Europe, particularly in Germany. Another e-ticketing platform, Moovel provides for some trip planning and standard ticketing functionality. Moovel is partnering most recently with LA and Baltimore.

JTA INTEGRATED MOBILITY APPLICATION BUSINESS REQUIREMENTS 10/16/2018

 Passport Labs, Inc: Passport Labs is mobile payments company specializing in integrated urban mobility solutions. The company provides feature rich software platforms that offer parking and transit agencies a more effective and efficient way to manage their operations and serve their customers.  Zed Digital (ZD): Zed Digital is a digital marketing and software development company that focuses on analytics and transit software solutions. ZD provides a transit platform for smart cities that is centered on multi-modal trip planning and ticketing. This platform is in use with the Central Ohio Transit Authority in Columbus, OH and other small agencies.

EXISTING ASSETS/RESOURCES

Currently, the JTA possesses and has deployed the following relevant applications. These applications were analyzed for any relevant functionality that should be brought into the IMA project. They are eligible to sunsetting as IMA develops.  myJTA: JTA’s MyJTA is a mobile e-ticketing application, available for iOS and Android platforms, produced by PassportParking Inc. The app allows customers to purchase and activate single ride tickets, 1-day, 3- day, 7-day and 31-day e-tickets, from the convenience of their mobile device. Customers can purchase e- tickets at anytime and anywhere with their smart phone, using a credit or debit card. Fares for the St. Johns River Ferry and Gameday Xpress are also available for purchase with the MyJTA app.  See’n’Say: This mobile application is developed by Elerts Corporation and put in production by the Safety & Security department of the JTA. JTA See & Say is a mobile application that makes it easy for individuals to communicate threats, safety and security concerns in real-time. It is concerned solely with reporting to and from customers and staff.  TransPortal: TransPortal is a regional multi-modal trip planning and paratransit trip booking (through an API with Trapeze) solution developed for veterans. It is browser-only, but responsive in design, meaning it can be used on desktops, laptops, tablets and smartphones through a compatible browser and will properly display itself on any device. It is an open source application that is constantly evolving in accordance with JTA’s contract with Cambridge Systematics, the developer.  NextBus: Provides bus arrival information by stop.  thebus.mobi: A simple website provided by MV that shows a Connexion user’s planned trips of the day. The following applications are notable integration targets for IMA within JTA:  Trapeze  Hastus  Oracle eBusiness Systems  CleverCAD

JTA INTEGRATED MOBILITY APPLICATION BUSINESS REQUIREMENTS 10/16/2018

PROCESS AND METHODOLOGY

The internal JTA project team for the development of this document was:  Joe Tenga, Chief Information Officer, Project Owner  Kevin Salzer, Transportation Innovation Officer, Project Lead  Paul Tiseo, Applications Manager, Project Lead The project team gathered input from several JTA business units to development this document. The process for gathering input was divided into the following three steps: 1. Identify subject matter areas for the IMA. 2. Identify subject matter experts (SMEs) for each area. 3. Interview SMEs. Step 1: Identify Subject Matter Areas (SMAs) The project team leads worked together to identify key subject areas that were necessary and essential to the IMA. The functional areas identified are listed below. Several subject areas aligned with existing JTA business units. Priority was given to functional areas already available today (e.g. safety and security, fixed route real-time arrival information, mobile fare payment, and trip planning). JTA transportation services not yet included in an existing JTA App were considered for inclusion in the future app. Step 2: Identify Subject Matter Experts (SMEs) A request was made to JTA executives and senior managers to identify appropriate SMEs for the subject areas. Once SMEs were recommended, the project leads scheduled interviews with the subject the SMEs. Subject Matter Areas Code Definition SMEs Customer C Customer feedback on current apps and future Cheryl Riddick needs. Voice of the customer. ADA ADA Experience living with a disability and using apps. Ken Middleton Equity E Title VI and experience with minority and low- Ken Middleton income neighborhoods. Fare Payment FP Review of existing mobile payment app and back Endya Freeman office support. Overview of fare payment industry. Trip Planning TP Existing JTA supported trip planning apps. Geanelly Reveron, Mark Wood Connexion CX Scheduling software and Connexion customer Geanelly Reveron, Mark feedback. Wood Fixed Route FR Operational technology systems that feed data to Carl Weckenmann current websites and/or apps; knowledge of customer feedback on current app.

JTA INTEGRATED MOBILITY APPLICATION BUSINESS REQUIREMENTS 10/16/2018

Subject Matter Areas Code Definition SMEs Ferry F Operational technology systems that feed data to Carl Weckemann current websites and/or apps; knowledge of customer feedback on current app. Safety and Security SS Current JTA safety app. Chris Geraci Legal L User agreements, data privacy, and data Khisha Dukes retention laws. Cybersecurity CS JTA cybersecurity strategies (especially for non- Joe Tenga, Paul Tiseo, JTA mobile devices and customer facing apps). Thomas Carroll Data Aggregation & DA Existing data sources and aggregations, John Harbison, Amber Analytics dashboards, metrics. Cabrera, Joe Tenga, Paul Tiseo, Kevin Salzer IT Support IT Experience maintaining and supporting existing Joe Tenga, Paul Tiseo JTA apps. Regional Transit RP Concerns of regional partners Geanelly Reveron, Liz Partners Peak

Step 3. Interview SMEs In order to benefit from sharing ideas, SMEs with closely related subject areas (e.g. maintenance and operations) were grouped together in interviews. Two general questions asked during each interview were:  What does JTA currently do now for this subject area?  What subject would be helpful to include in a future app?

Based on the answers to these questions, follow-up questions were asked to understand:  How the subject areas were handled by the SME’s business unit?  What aspects of the subject area are challenging or inefficient today?  What aspects of the subject areas are working well and should be carried forward?

The answers to the two general questions and follow-up questions were documented by the project team project leads.

BUSINESS REQUIREMENTS

Business requirements are the critical activities of an enterprise or project that must be performed by the software to meet the organizational objectives while remaining non-committal on the detailed implementation. This sections captures the business requirements for IMA obtained during meetings with the SMEs:

Number SMA Business Requirements 1. C Customer must be able to easily identify bus stops without bus ID 2. C Customer must be able to access any service provider’s posted transit schedule

JTA INTEGRATED MOBILITY APPLICATION BUSINESS REQUIREMENTS 10/16/2018

Number SMA Business Requirements 3. C Service provider staff should be able to track the number of app users in a given time frame 4. C Customer should have the ability to receive detour alerts 5. C Customer should be able to display hub specific route maps showing only the routes that connect to the given hub 6. C Customer should be able to show map/visual of stops within airports, JRTC, and other major buildings. 7. C Customer should be able to identify points of interest/local activities 8. ADA Customer should be able to enable verbal wayfinding features to navigate transportation services 9. ADA Customer should be able to enable visual and verbal alerts that notify them before arrival so that the customer can make a stop request and prepare to depart 10. CX Customer should be able to send and receive scheduling information through Trapeze and schedule Connexion Trips 11. CX Service provider staff should be able to send messages to notify customer of eligibility expiration 12. CX Customer should be able to identify distance of upcoming ride or expected time of arrival 13. CX Customer should be able to access his or her customer profile 14. E App must be accessible and formatted for a desktop computer 15. E App must be compatible for staff at call center to assist customer 16. E App payment services should be compatible with JTA Star Card 17. FP Customer must be able to purchase rides through the app 18. FP Customer must be able to conveniently cancel payments for unwanted purchases 19. FP Service provider staff must be able to verify trip purchases 20. FP Customer must have ability to reload star card online 21. FP Service provider finance staff must be able to provide a refund to a customer when purchases are made in error 22. FP App should include streamlined method for service provider finance staff to reconcile payments each month 23. FP App should include method for service provider finance staff to run reports that explains amounts by mode and fare type 24. FP App must be able to accommodate unbanked individuals 25. TP Customer must be able to plan trips by inputting origin, destination, and start time 26. FR Customer must have the ability to take pictures of bus stop number or way to verify stop location for complaints/maintenance requests 27. FR Customer should be prompted to include bus number in complaints/maintenance requests to know if bus is inbound or out outbound 28. FR Service provider maintenance staff should be able to know when the next time a bus will be at the hub so that the bus can be serviced 29. FR Service provider maintenance staff should have an Oracle compatible app to respond to requests in the field

JTA INTEGRATED MOBILITY APPLICATION BUSINESS REQUIREMENTS 10/16/2018

Number SMA Business Requirements 30. F Customer must be able to easily purchase ferry tickets for small groups or individuals 31. SS Customer must be able to report safety Incidents 32. SS Customer must have the ability to send safety messages to predefined groups 33. SS Customer must be able to report hazards for service provider to review 34. SS Customer must have the ability to discreetly send video and pictures for service provider Safety and Security Staff or Operation Staff to review 35. SS Customer must have the ability to send GPS location coordinates with safety and security messages to service provider 36. SS Service provider staff must have the ability to assign levels of alert to safety and security messages 37. SS Customer must have the ability to remain anonymous in reporting safety and security concerns 38. L Customer must read and agree to a terms of use agreement to use the app 39. L Customer should have the ability to opt in or out of personal data collection 40. DA App should allow social media login 41. DA Provider staff should have the ability to send surveys through the app 42. CS App should comply with current cybersecurity standards (ISO, PCI, NIST) 43. CS App should have appropriate security measures to protect personal privacy data (FIPA, HIPAA) 44. CS App should have appropriate data encryption to ensure confidentiality 45. CS Customer should have a means to identify customer’s driver and vehicle during pickup when using in demand response transportation services 46. IT Vendor should provide a release schedule of app updates and future builds 47. IT Vendor should support ongoing UI/UX 48. IT Vendor should provide split testing of the app 49. IT Vendor should self-report uptime of the app 50. IT App must be integrated with Native OS 51. AR Customer should be able to view weather information 52. AR App should enable the display of third party advertisements that JTA permits 53. AR App must accept a regional fare and track the providers used by the regional fare customer. 54. AR Customer must be able to book trips with private transportation providers (e.g. bikeshare, carshare, microtransit, commuter rail, AVs) 55. AR App should enable the booking of multimodal trip itineraries incorporating several transportation providers 56. AR Customer should be able to compare multiple trip itineraries and prioritize based on wait time, trip time, and cost 57. AR Customer should be able to input and save preset preferences to his or her profile prioritize wait time, trip time, cost, and transportation provider

JTA INTEGRATED MOBILITY APPLICATION BUSINESS REQUIREMENTS 10/16/2018

Number SMA Business Requirements 58. RP App permission levels should allow a partnering agency to run reports that explains the number of rides their vehicles have provided and the revenues collected via the app. 59. RP Regional and multimodal partner agencies must be able edit their agency’s information, respond to their customer inquiries or safety and security reports.

FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS

Overall Platform Description The platform will consist of one or more client applications, including at least one responsive-design, browser- based client and at least one mobile device client, a middle-layer/gateway server that presents an API for any client and mediates data transfers between clients and the database layer, and a database/data-persistence backend. A separate, browser-based, responsive application should be provided and function as an administrative console for managing the configuration and monitoring the platform.

Mobile User

Application Gateway Database (API)

Desktop/Laptop User Requirements List These are the functional and non-functional requirements that are either derived from the business requirements above or added independently of them. This is a “living list” and should be added or enhanced as the project develops. 1. FUNCTIONAL 1.1. Users, Registration & Logins 1.1.1. The platform must allow a user to create his or her own login, with email as username and a password.

JTA INTEGRATED MOBILITY APPLICATION BUSINESS REQUIREMENTS 10/16/2018

1.1.2. The user’s profile will contain the following fields: username (always email, mandatory), first name, last name, alternate email, DOB, password (mandatory), full address (separate fields), phone number, SMS-allowed, gender and nationality. (With appropriate disclaimers) 1.1.3. User email address must be validated via email verification. 1.1.4. The platform must allow a user to login via Facebook or Google accounts. 1.1.5. The platform should allow a restricted “guest” access mode that heavily limits functionality. Permitted functions should be configurable by allowed users via the administrative console. 1.1.6. A logged-in user should be able to view and edit any field in their profile, excluding username. 1.2. Accounts 1.2.1. The platform must allow a user to aggregate or link logins under one account or like mechanism via an invitation process, where the invited user must accept to be included. 1.2.2. Payment methods and stored credits can be shared across accounts by name (no credit card data is visible to linked users). 1.2.3. Booked trips can be transferred between linked logins in an account. 1.3. User Management 1.3.1. Allowed users can add, delete and edit users. 1.4. Trip Planning & Management 1.4.1. The system must be able to account for multiple transit service providers. 1.4.2. All users must be able to access a provider’s posted transit schedule. 1.4.3. A user must be able to select a hub on a map and view the routes and trip options starting or ending on that hub. 1.4.4. Services and modes must be mapped to specific service providers. 1.4.5. All users must be able to plan a trip with one or more legs based by supplying a starting point (by address, hub, common destinations or other options), an end point, and one or more intervening points. 1.4.6. The starting point of a planned trip may be user-supplied or set to the current GPS coordinate, if locations services are available. 1.4.7. The user may stipulate any duration they’d like to spend at any point on the trip. 1.4.8. The user may filter to specific services, such as fixed route, paratransit, external ride-sharing services, etc. 1.4.9. The user must be able to specify the trip definition via voice. 1.4.10. The system must return all matching trips showing each leg of the trip. 1.4.11. The list of matching trips must be sortable by useful criteria, such as total cost, total time, etc. 1.4.12. The matching list must be paged to a user-defined number of trips, with a default of 10. 1.4.13. For each proposed trip, the provider, service, start and end times, duration and cost must be shown. Duration between each leg must be shown. 1.4.14. The platform will need to store when the service is available. 1.4.15. The trip’s total cost must be shown to the user. 1.4.16. All trip searches should be saved to the platform. 1.4.17. Users can view a list of all booked trips, past or future. 1.4.18. Users can reuse a previous booked trip.

JTA INTEGRATED MOBILITY APPLICATION BUSINESS REQUIREMENTS 10/16/2018

1.4.19. Users can schedule a recurrent trip. Recurrence should offer options of: daily, specific days of week, monthly, specific dates of month. Recurrence should be open-ended, for a fixed number of trips or an end date. 1.4.20. The user must select a trip to initiate booking and payment. The user must be presented with a “quick pay” path, that uses a primary payment method, and a regular payment path. (See Payment Processing requirements.) 1.4.21. A user can buy multiple quantities of each booking. 1.4.22. For modes/services with a reservation aspect, the application must be able to show a seat/slot map with open, reservable choices, then allow the user to select and reserve the desired seats/slots they want to use on each leg of such a trip. 1.4.23. For recurrent trips, the user must pay for at least the first trip at the time of booking a recurrent trip. Subsequent trips must be paid in advance to activate and should be visible from the user’s list of bookings. 1.4.24. A logged-in user must be able to pull a ticket on screen for presentation from any device. 1.4.25. Tickets must be presentable in two modes, such that they can be visually validated by an operator, or scanner validated. 1.4.26. All mobile tickets will include the following: a high security image with anti-tampering features, a barcode / QR Code, the JTA agency logo, validity period, and the fare type. 1.4.27. Users must be able to store personal information relevant to trip planning. This includes, but is not limited to, the following: mobility aids, medical conditions, service animals, etc. User must be able to apply any and all such defaults to the trip planning process. 1.4.28. Allowed users can view planned trip searches, booked or not, in a tabular form in the administrative console. The report data is exportable as XML, JSON, CSV or Excel. 1.4.29. Trip data can be accessed by API, in bulk or one report at a time. 1.4.30. Trips may optionally present parking information as the start point. 1.4.31. Allowed trips that are loaded into the system should be manageable by allowed users. These users can disallow trips (for a time duration, to a certain date, always), add an internal comment, add an external comment, add discount (for a time duration, to a certain date, always). 1.4.32. Planned trips (see 1.4.15) should be reviewable offline if a user does not have internet connectivity. 1.5. Fare & Payment Processing 1.5.1. When a user selects a trip in the list, the system will ask for a payment method. 1.5.2. Allowable payment methods include, but are not limited to: credit cards, debit cards, PayPal, EBT, cryptocurrencies, etc. 1.5.3. The user may store data on payment methods in their account, name the method (ex: “main credit card”), mark one as “primary”, and re-use them via drop-down in various other parts of the application. 1.5.4. Payments can be banked/stored for subsequent use. 1.5.5. All payments must be confirmed and allocated with relevant provider systems via API, to then be confirmed to the end user.

JTA INTEGRATED MOBILITY APPLICATION BUSINESS REQUIREMENTS 10/16/2018

1.5.6. Allowed users can add credit to a user/login. The user performing this action must be logged, with date, time, place and any other relevant audit trail information. 1.5.7. STARCard integration (see 3.4 for details). 1.5.8. Must offer ApplePay on iOS devices. 1.5.9. Must offer AndroidPay on Android devices. 1.5.10. Users must be able to cancel a trip. (Some legs, especially via third-party may not be cancelable. System must be able to maintain cancelation rules for such third-party, per trip if necessary, and inform the user.) 1.5.11. Canceled trip must be refunded depending on booking agreement/terms. 1.5.12. Allowed users must be able to cancel trips and issue refunds on behalf of any user. 1.5.13. Allowed users can view planned trip searches, booked or not, in a tabular form in the administrative console. The report data is exportable as XML, JSON, CSV or Excel. 1.5.14. Transaction data can be accessed by API, in bulk or one report at a time. 1.5.15. User can seamlessly validate paid fares via Bluetooth-based token systems by being aware of validation zones. 1.5.16. Must be able to integrate with eligibility validation services and able to manage discounting fares. 1.6. Real-Time Interactivity 1.6.1. Show user an interactive map with current position, routes, stops, current location of vehicles and other real-time data. 1.6.2. If user clicks/taps on a stop, the client should display stop information, next bus arrival time and other contextually-relevant information. 1.6.3. The app shall function as a geo-aware digital assistant in real-time, offering relevant alerts, warnings and notifications. 1.7. Reporting Safety Issues 1.7.1. User must be able to effectively and quickly report security or safety concerns via a form in the application. 1.7.2. The user form contains the following fields: a multi-select concern picker, an area for user comments, a UI control for taking one or more pictures, a location selector via a map or an autocompleting text field. 1.7.3. The location selectors (map or autocomplete) must be GPS-aware on devices with location services. 1.7.4. For each field of the form, client must provide a way to popup a help dialog. The text in dialog should be configurable by allowed users. 1.7.5. The form will automatically collect all relevant metadata available on the phone and file it with the user form. 1.7.6. An additional form control allows a user to indicate anonymous reporting, which will strip the collected metadata and file the report in a fully anonymous fashion. 1.7.7. User must be able to save a report if there is no network connectivity when filling in the form 1.7.8. Saved/pending forms must be sent as soon as network connectivity is returned and without user intervention 1.7.9. When in reporting mode, any camera flash and sound on the device must be disabled by default.

JTA INTEGRATED MOBILITY APPLICATION BUSINESS REQUIREMENTS 10/16/2018

1.7.10. Allowed users must be able to add, delete or edit items in the list of allowed concerns in the administrative console. 1.7.11. Allowed users can view reported issues in a tabular form in the administrative console. The report data is exportable as XML, JSON, CSV or Excel. 1.7.12. The report data can be accessed by API, in bulk or one report at a time. 1.8. Notifications & Alerts 1.8.1. Allowed users must be able to create notifications that will be pushed to users 1.8.2. The system can additionally push various types of notifications, such as: upcoming planned trips, nearby buses, surveys, detours, emergencies, change of service/schedule, driver en route, eligibility expiration, next day reminders, etc. 1.8.3. Push notifications must be targetable by, but not limited to: geographical area, groups, tags, etc. 1.8.4. User can select to receive push notifications and SMS notifications. Users must be made aware in a non-interruptive way, and user must be able to disable this behavior. 1.9. Surveys 1.9.1. Allowed users can create surveys to push to users. 1.9.2. Surveys pushed to users must be targetable by, but not limited to: geographical area, groups, tags, etc. 1.9.3. Users fill out the survey form and the client sends the collected survey data to the server. 1.9.4. Allowed users can view all surveys and results, if any. The survey data is exportable as XML, JSON, CSV or Excel. 1.9.5. The survey data can be accessed by API, in bulk or one survey at a time. 1.10. Data Management 1.10.1. The administrative console must provide a dashboard that a user may personalize with a catalog of widgets. 1.10.2. The administrative console must be able to report on and filter the following central record types: riders, routes, trips & legs thereof, transit modes, etc. 1.11. Social Media Support 1.11.1. A user can link their login to various social media services. 1.11.2. A user can post specific events to social media, such as “I just booked a trip on 1.12. Gamification 1.12.1. Allowed users can create badges that consist of a name, an icon, a description, and a qualifying criteria rule system. 1.12.2. The system can award “badges” to users by monitoring activity data and seeing if it matches a badge qualifying rules. 1.12.3. Users must actively opt-in to the gamification subsystem. 1.12.4. Users can view all active badges by name and icon, and information can be viewed via popup. The view can be sorted or filtered. 1.12.5. Allowed users can generate and export reports from the administrative console of users and badges. 1.13. Support 1.13.1. The platform will provide a mechanism for users to send suggestions, questions or comments.

JTA INTEGRATED MOBILITY APPLICATION BUSINESS REQUIREMENTS 10/16/2018

1.13.2. The support request form will contain the typical “Contact Us” fields. 1.13.3. Allowed users can generate and export reports from the administrative console of users’ communications. 1.13.4. The data must be integrated with JTA’s customer service CRM platform. 1.13.5. User can access contextual chat-based system to assist in using the application or to field common JTA questions. 1.13.6. The system leverages chatbots to supplement 1.13.5. 1.13.7. User can access a searchable knowledgebase. 1.14. Auditing 1.14.1. All actions taken by any user in the platform must trigger events that must be recorded in the database. 1.15. Miscellaneous 1.15.1. The client can report on weather conditions 1.15.2. The client can display ads. List of allowed ads must be manageable by allowed users. 1.15.3. The client can display events, notably JTA events. Trip planning can be launched from events. 2. ACCESSIBILITY 2.1. ADA 2.1.1. The clients must conform to the Web Content Accessibility Guidelines 2.1, Level AA, published by the World Wide Web Consortium. 2.1.2. The clients must abide by relevant items from Section 508 of the Rehabilitation Act. 2.1.3. The clients will provide real-time audio cues of relevant information, such as alerts & notifications, stops, arrival times, etc. 2.1.4. The vendor shall provide evidence of compliance for each release build of any element/system in the platform. 2.2. Localization 2.2.1. The user must be able to specify a particular locale that would alter the interface to respect numeric, date and time formats, currency usage, keyboard usage, text direction and symbols per the requirements of each locale. 2.2.2. Locales should include: en, en-gb, es and others to be determined. 2.3. Internationalization (i18n) 2.3.1. The user must be able to specify a preferred language per device and all text on the app on that device will be presented in that language 2.3.2. The strings must be stored in a configuration file that can be edited in a text editor by a system administrator. 3. INTEGRATION 3.1. LDAP 3.1.1. The platform should be able to be integrated with Active Directory via LDAP 3.2. Oracle e-Business System (Oracle) 3.2.1. The platform must be integrated with Oracle EBS platform. 3.3. Trapeze (SPX) 3.3.1. The platform must be integrated with SPX’s Trapeze.

JTA INTEGRATED MOBILITY APPLICATION BUSINESS REQUIREMENTS 10/16/2018

3.4. AFM/STARCard (Productive Solutions) 3.4.1. The platform must be integrated with Productive Solution’s AFM system. 3.5. HASTUS 3.5.1. The platform must be integrated with JTA’s HASTUS platform, primarily to pull fixed-route information. 3.6. API 3.6.1. The platform must provide a rich API that gives JTA and affiliates access to the majority of the data. 3.6.2. Platform must offer a way for service providers to push data about available services and costs by provider. 3.6.3. The API shall be designed so as to accept JSON or XML, and return JSON or XML. 4. UI/UX 4.1. Personalization 4.1.1. Each client application should be themable by allowed users with respect to fonts, colors, backgrounds, buttons, images, iconography, graphs and charts, etc. This should be manageable by allowed users. 4.2. Reporting Safety & Security Issues 4.2.1. Navigating to the Safety form should always be one step/click/link/menu option away for the user’s current context. 4.2.2. The Safety form should be accessible without having logged in. 4.3. UI 4.3.1. Users must be able to control the client application font size. 4.3.2. The application looks and functions in a manner consistent with the operating system it is run on. 4.4. Language 4.4.1. All language in the clients must be written at an 8th grade level 4.5. Miscellaneous 4.5.1. User must be able to easily identity bus or other transportation mode stops without an ID. 5. PERFORMANCE 5.1. Client-side 5.1.1. Mobile application experiences sub-second server response time (.5 seconds), measured as the time the webserver receives a request to the time it is ready to return a response to the calling application. 5.1.2. UI loads completely from time of request within 3 seconds. 5.1.3. UI responds within 1/4 second of short tap or click. 5.1.4. UI responds within ¼ second upon release of a long tap or click. 5.1.5. UI responds immediately to a swipe. 5.2. Server-side 5.2.1. Must support at least 5000 concurrent users 5.2.2. Must be available 24hrs per day, 365 days per year 5.2.3. You must be able to run multiple instances of the Gateway Server. 5.2.4. The platform must leverage web server data caching to minimize database access. 5.2.5. The gateway server can be active-active load-balanced.

JTA INTEGRATED MOBILITY APPLICATION BUSINESS REQUIREMENTS 10/16/2018

5.2.6. Ensure the Mobile application platform will support up to 5 million registered users 5.2.7. Emphasize the use of the mobile device's processor rather than the Web Server to render UI elements 6. PORTABILITY 6.1. Client Platforms 6.1.1. Client application must run on Android v4.0 or greater. 6.1.2. Client application must run on iOS v10.0 or greater. 6.1.3. Client application must be useable on tablets and smartphones. 7. SECURITY 7.1. Local Authentication 7.1.1. Password must meet the following minimum complexity requirements: minimum of 8 characters, require one of each [lowercase, uppercase, numeric, non-alphanumeric], cannot have more than 2 consecutive identical or sequential letters. 7.1.2. Passwords must be checked against a blacklist. 7.1.3. Passwords expire every 90 days. 7.1.4. Password must be stored as a secure hash. 7.1.5. Password entry areas on any client must be obfuscated/hidden and not visible text. 7.1.6. Five failed logins will trigger user lockout. 7.1.7. User may reset account via emailed reset link (to the username and alternate email) or via SMS (if provided and allowed). User can select when resetting. 7.1.8. Allowed users may unlock logins. 7.1.9. Usernames (emails) must be checked against a blacklist to disallow registration or updates. 7.1.10. System must allow multi-factor authentication, including one or more of the following modes: automated call, automated SMS, fingerprint, facial recognition, etc. 7.2. Sessions 7.2.1. Client sessions should automatically log out after inactivity after 10 minutes. 7.3. Role-Based Access Checks 7.3.1. The platform must allow users to be put into groups 7.3.2. The default groups include: system administrators, agents and riders. 7.3.3. Any user can be in one or more groups. 7.3.4. Each administrative action must be associated to a permission. 7.3.5. Any group can be associated with any permission. An association will be qualified as allowed or denied. 7.3.6. A user will gain all permissions across all group the user is in. A denied permission will override any allowed ones. 7.4. API Security 7.4.1. The platform will allow users to generate API tokens that confer access to API functionality. 7.4.2. The token will confer the same permissions as the user who generated it. 7.4.3. Token lifetime can be set by user who is generating the token. 7.4.4. Users can view all their token and can void any at any time.

JTA INTEGRATED MOBILITY APPLICATION BUSINESS REQUIREMENTS 10/16/2018

7.4.5. Token and token metadata (such as expiration date) should be stored in database. Requests against the API with an invalid (Voided, expired, etc) token should be detected and stopped. 7.4.6. The API shall be resistant against unexpected flood of requests (which could be a real unexpected load-peak, the result of errors in the calling application resulting in infinite number of retries, or an intentional attack). 7.4.7. The API must guard against malicious code injection. 7.4.8. All API calls must be logged and associated to the token used. API calls must be connected to the user. 7.5. Networking & Connectivity 7.5.1. Ensure that data exchanged between the server and the app is transmitted via an encrypted protocol accepted as a secure method (e.g. HTTPS) 7.5.2. Ensure that data exchanged between the application and the database/storage backend is transmitted via an encrypted protocol accepted as a secure method. 7.5.3. 7.6. Database 7.6.1. Database must be encrypted at rest. 7.7. Tickets 7.7.1. When a ticket is presented for visual validation, it must include anti-tampering features that prevent use of image or video copies to allow multiple riders on one activated ticket. 7.8. Miscellaneous 7.8.1. Ensure that no unencrypted PHI will be stored on any client 7.8.2. System must offer the ability to geofence users. 8. RELIABILITY 8.1. SLAs 8.1.1. The platform must meet 99.99% availability/uptime. 8.1.2. The platform must have been in production at one or more customers in the United States for at least 6 months. 8.2. Miscellaneous 8.2.1. Vendor must be able to produce a defect backlog report upon request, and respond within 3 days. 9. IMPLEMENTATION 9.1. Architecture 9.1.1. The administrative console must be a separate application that can be hosted on a separate server than any other client. 9.1.2. Must have an open API. 9.2. Maintainability & Documentation 9.2.1. The platform will utilize a ubiquitous development language that aids ability to readily find qualified human resources at reasonable rates. 9.2.2. The vendor will provide a robust data dictionary that covers all objects in the database/persistence layer. 9.2.3. The vendor will provide online, web-based API documentation aimed at developers. The format will be specified separately. 9.3. Miscellaneous

JTA INTEGRATED MOBILITY APPLICATION BUSINESS REQUIREMENTS 10/16/2018

9.3.1. If the platform makes use of open-source libraries, the libraries must be provided, along with their licensing model. 9.3.2. Licenses that trigger open sourcing of proprietary code is not allowed. 10. STANDARDS & COMPLIANCE 10.1. Legal Disclaimers 10.1.1. New users must agree with a Privacy Statement. The agreement acceptance must be recorded in the database. 10.1.2. New users must agree with the Terms of Use screen. The agreement acceptance must be recorded in the database. 10.2. Data Retention 10.2.1. Platform will follow storage, maintenance and destruction of information requirements 10.3. PCI-DSS 10.3.1. The vendor will maintain continuous compliance with the latest Payment Card Industry (PCI) data security standards, including all audit and compliance certification activities. 10.3.2. The vendor will provide evidence of third-party audit of PCI-DSS compliance. 10.4. Miscellaneous 10.4.1. The vendor should maintain continuous compliance with NIST 800-53 or equivalent. 10.4.2. The vendor will provide evidence of third-party audit of 10.4.1. 11. VENDOR 11.1. Support 11.1.1. Vendor is expected to be able to provide phone and email support on a 24/7/365 basis. 11.1.2. The vendor is expected to be able to provide training via web. 11.1.3. It is preferred that the vendor can also provide local, instructor-led training. 11.2. Revenues 11.2.1. The developer will deposit fare revenues (minus applicable fees and taxes) into the designated JTA bank account on schedule to be agreed upon in the service contract.

RECOMMENDATIONS

The project leads recommend JTA move forward in the development of IMA. The next recommended step is to release a request for information (RFI) that includes the information provided in the previous sections, especially the requirements. This would allow the industry to inform JTA of the feasibility of the requirements and potential approaches to funding and developing IMA. Prior to the RFI, JTA staff also recommends further research into two important areas:  Useful life of existing customer facing information systems  Input from stakeholders with disabilities JTA has already invested in several existing customer facing information systems and some of these systems have been paid for with grant funding. The useful life of these systems will need to be included in the RFI. This will

JTA INTEGRATED MOBILITY APPLICATION BUSINESS REQUIREMENTS 10/16/2018

enable RFI respondents to prioritize those systems that JTA has a financial obligation to keep when considering integration of legacy JTA systems into IMA. JTA recognizes the importance of developing IMA as a universally accessible mobile application. Significant advances in smartphone applications have been made to enable persons with disabilities to navigate the Internet and the physical world. The project leads will meet with JTAC, JTA's advisory committee for Connexion, to gather feedback for IMA from those with firsthand experience with disability and app technologies.