Attachment_03_Functional_and_Technical_Requirements_Matrix_Final.xlsx
XLSX spreadsheet 29 KB Posted
- Attached to
- Mobile App Replacement
- Solicitation number
- S-177000-00016166
- Issued by
- Marion County, Oregon
About this file
This is a Functional and Technical Requirements Matrix for RFP #S-177000-00016166, issued by the Oregon State Lottery (OSL), outlining specifications for a mobile app replacement solution. The project encompasses a comprehensive digital platform enabling players to submit and track claims, manage payments via ACH, receive communications through multiple channels, view game information across draw games, instant games, and video lottery terminals, access Second Chance entries, scan tickets, search retailer locations, manage digital coupons, and register at multiple verification levels. The solution must integrate with OSL's existing central gaming system (Aurora/BSL), Intelligen for VLT games, iMarcs for Second Chance functionality, the Anywhere API for ticket scanning, and LexisNexis for Know Your Customer (KYC) verification, with provisions for vendors to propose alternative systems in specified areas. Key functional requirements include mobile claims with photo ID and ticket uploads and signature verification; mobile payments in configured ranges ($400-$5,000 for traditional games; $1,200-$5,000 for video lottery games) with ACH authorization and configurable auto-approval thresholds; player communications via text, push notifications, email, and in-app messaging; comprehensive game information with digital playslips and quick picks; geolocation-enabled Second Chance entries with player attestation options; and full ADA WCAG 2.1 compliance. Current volumetric data indicates approximately 15,000-23,000 monthly active users, with significant transaction volumes including nearly 5 million ticket scans and 1.2 million Second Chance entries in December 2025.
The solution must comply with OWASP Mobile Application Security guidelines, prohibit VPN access, and maintain security certifications such as ISO 27001 or FedRamp. A comprehensive data repository must store all player administrative information migrated from existing Akamai systems, with configurable access roles and retention policies. OSL requires Power BI reporting and self-service analytics capabilities, including standard canned reports and dashboards covering player scan history, Second Chance entries, device and geolocation data, and fraud detection metrics. The vendor must provide documentation for data model, data dictionary, refresh latencies, and access controls to enable OSL's existing Microsoft Power BI environment to connect for ad hoc reporting. The solution must support multiple iOS and Android versions, include account closure functionality compliant with Apple App Store and Google Play requirements, and integrate with Oregon State Treasury Third Party vendor requirements. Proposers must complete the matrix by indicating whether each requirement can be met as baseline functionality, through configuration, or cannot be met, with detailed explanations addressing implementation approaches, dependencies, and any mitigation strategies or alternative solutions.
View the file
Other files
Show all 22
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Template Instructions
| RFP #S-177000-00016166 Functional and Technical Requirements Matrix |
| Proposer Instructions |
| 1. Columns to Complete: |
| Populate all columns C–F ("Proposer Ability to Meet Requirement") for each functional requirement listed. |
| These columns are: |
| Column C: Indicate if you can meet the requirement with your Baseline Solution. |
| Column D: Indicate if you can meet the requirement with Configuration. |
| Column E: If you cannot meet the requirement, mark accordingly. |
| Column F: Provide a clear Explanation describing: |
| How and to what extent your solution meets or exceeds each requirement. |
| Any dependencies or prerequisites for meeting the requirement. |
| If not met, provide reasoning/mitigation or suggested alternatives. |
| 2. Context Columns: |
| The “Nice to Have” column (G) provides context but does not require proposer input; use it to inform your approach. |
| The “Technical Requirements” column (H) offers more insight into Additional Proposed Solutions the Lottery may benefit from. Proposers may describe supplementary solutions addressing these requirements as part of Optional Proposal Section 3.4. |
| 3. Level of Detail: |
| Be specific and avoid vague responses. |
| If multiple options exist, summarize them in the Explanation. |
| 4. Completeness: |
| Respond to every Functional requirement listed. |
| Incomplete or ambiguous responses may negatively impact proposal evaluation. |
| 5. Formatting: |
| Do not alter the structure of the template. |
| Attach the completed matrix as part of your proposal submission. |
Mobile App Requirements
| RFP #S-177000-00016166 Functional and Technical Requirements Matrix | |||||||
| Business Requirements | |||||||
| A business requirement describes the high-level needs, objectives, or goals an organization aims to achieve with the project. It explains “why” the project or solution is needed, guiding the overall direction and value to the business. | Functional Requirements | ||||||
| A functional requirement specifies what the system, product, or solution must do, the specific features, behaviors, or functions to be implemented. It explains “what” the system should accomplish to meet the business need. | Proposer Ability to Meet Requirement | Additional Context | |||||
| Proposer Can Meet as Part of Baseline Solution Functionality (e.g., available with no configuration) | Proposer Can Meet with Configuration | Proposer Cannot Meet | Explanation | "Nice to Have" Functional Requirements | Technical Requirements |
A technical requirement outlines the technical constraints, platforms, standards, or technologies that must be considered for implementing the solution. It details “how” the system will be built and what technical parameters must be followed.
| OSL solution Upgrade: Connected Play Capabilities |
| 1. New OSL solution: OSL shall deliver a mobile app replacement solution that significantly elevates player convenience, engagement, and satisfaction. The new solution will provide seamless, secure options for players to manage key lottery activities, including submitting and tracking claims and payments, directly from the solution. It will streamline navigation, eliminate unnecessary steps in core workflows, and modernize features to ensure the solution not only aligns with but anticipates evolving customer expectations. The solution must set a new standard for accessibility, intuitive design, and rapid access to lottery services, enabling OSL to drive player retention and reinforce its position as an industry leader. The solution shall also allow for the potential addition of iLottery functionality in the future, if policy / regulations should be released that allow for this feature. |
1.1 Mobile Claims: The solution shall facilitate the process of a player submitting a claim digitally. A player shall be prompted to upload images of the following upon each claim submission: Photo ID (front only), Ticket (front and back) Security asked to require a player 'selfie' picture with their ID to submit a claim.
OSL would like a service that verifies player signature (e.g., on Photo ID and ticket). The solution shall connect to OSL central gaming system, following one of 2 potential paths:
1) integrate with current BSL central gaming system (Aurora), if vendor is only providing a response that includes a digital solution for claims and payments. If bidder follows this path, the solution will need to create National Automated Clearing House Association (NACHA) files for Key Bank.
2) propose an alternative central gaming system in the "Additional Proposed Solutions" section of the RFP, if vendor could provide this technology. The central gaming system must, at minimum, comply with the following requirements:
-Integrate with Intelligen -Integrate with D365, M365, and Azure -Meet Treasury Requirements
1.2 Mobile Payments: The solution shall facilitate the distribution of payments via ACH in the following initial ranges, with the ability to adjust the ranges over time, via integration with the central gaming system:
For Traditional Games: $400 - $5,000
| For Video Lottery Games: $1,200 - $5,000 | OSL would like a secondary mobile payment option to ACH (must be Treasury approved) for players without bank accounts. | |||
| 1.2.1 The solution shall include a mechanism for ACH authorization. | ||||
| 1.2.2 The solution shall comply with Oregon State Treasury Third Party vendor requirements: https://www.oregon.gov/treasury/public-financial-services/Documents/Public-Financial-Services-Cash-Management/FIN214.pdf | ||||
| 1.2.3 The solution shall provide a means of saving player bank account information so that players are only required to enter this information the first time they receive a mobile payment. | ||||
| 1.2.4 The solution shall allow for a configurable range of mobile claims to be automatically approved and paid out, while all other claims will be sent to Player Services for review and approval. | To begin, OSL would like for mobile claims between $400 and $600 to be automatically approved and paid out. | |||
| 1.2.5 The solution shall allow for a fee to be deducted from mobile payments, to cover mobile transaction (and other relevant) costs. This fee shall also be reflected in the Central Gaming System and relevant financial documentation. | ||||
| 1.3 Player Communications and Notifications: The solution shall allow communication with the player, via text, push notifications, email, and in-app messaging capabilities. The solution shall also provide players real time updates regarding draw times (including Second Chance), jackpot changes, ticket status, and promotional offers. | The vendor may propose their own CRM solution in the "Additional Proposed Solutions" of the RFP. | |||
| 1.3.1 The solution shall allow both anonymous and registered players to receive notifications. | ||||
| 1.4 Game Information: The solution shall provide comprehensive details for each game type, to include: |
-Play Instructions -Prize structure -Draw-time counters -Promotional content and offers -Real-time updates
1.5 Draw Games: The solution shall provide comprehensive capabilities for the following draw games:
-PowerBall -Mega Millions -Oregon's Game Megabucks -Cash Pop -Win for Life -Pick 4 -Raffle -Lucky Lines -Keno
Capabilities shall include:
-Digital Playslips, allowing players to define the draw games wager they want to buy without using paper playslip or verbally describing their wager to a retailer -Quick Picks -Pick Your Numbers
| -Displaying tickets remaining, for Raffle only | Dynamic animation, for Keno only. | |||
| 1.6 Instant Games: The solution shall provide comprehensive capabilities for players to view the details for instant games. | ||||
| 1.7 Video Lottery Terminal (VLT) Games: The solution shall provide comprehensive capabilities for players to view the details for VLT games. | The solution shall integrate with IGT's VLT system (Intelligen). | |||
| 1.8 Second Chance: The solution shall allow players Second Chance entry for instant and draw game tickets and display the history of these entries. | The solution must integrate with vendor iMarcs, unless bidder has a Second Chance solution they can provide. | |||
| 1.8.1 Geolocation shall be enabled for Second Chance entries to confirm players are in Oregon; if players do not have geolocation services turned on, the solution shall prompt a player “attestation” to confirm they are within the state of Oregon. | ||||
| 1.9 Retailer Location: The solution shall allow players to search for lottery retailers using their device's geolocation or via city / zip code. The solution shall display hours of operation and available products for each location. | Marketing requested photos to be uploaded for retailers. | |||
| 1.10 Ticket Scanner: The solution shall allow players to scan lottery tickets to determine if they are winners. | The solution shall integrate with existing Anywhere API to check tickets. | |||
| 1.10.1 For Second Chance entries, the solution shall allow a player to manually enter a ticket, in the event it is unreadable/damaged. | ||||
| 1.11 Favorites: The solution shall allow players to save and manage their favorite lottery numbers and games. | ||||
| 1.12 Results: The solution shall allow players to view winning numbers, by date and specific game, and the remaining prizes of an instant game. | The solution shall integrate with the current OSL website to avoid needing duplicate Results updates. | |||
| 1.13 Digital Coupons: The solution shall allow players to receive digital coupons that can be redeemed for certain games and / or at retail locations. | ||||
| 1.14 Registration: The solution shall provide for multiple levels of player registration, according to the functionality the player wishes to access: |
-No registration: Anonymous players can still access application functionality, except for Second Chance entry and mobile claims and payments.
-Level 1: Players can enter Second Chance, which requires verification of their age (age 18 for traditional games) -Level 2: Considered full registration, players are eligible to submit a mobile claim and receive a mobile payment, once they have verified a minimum of the last 4 digits of their SSN and other specified details (e.g., age 21 for VLT games). OSL would like for existing players to be able to use their existing password for initial login. The solution shall allow for Know Your Customer (KYC) functionality, fulfilling functional registration requirements by 1 of 2 potential paths:
1) Integrate with OSL existing KYC solution (LexisNexis)
2) Propose an alternative KYC solution in the "Additional Proposed Solutions" section of the RFP, if vendor could provide this technology.
1.15 OSL-Specific Content: The solution shall link to existing OSL content to avoid needing to update information in duplicate mediums:
-Privacy Policy -Terms and Conditions -Game Play instructions -Game Prize Structure -Game Images -Responsible Gaming -Frequently Asked Questions (FAQs) The solution shall fulfill functional OSL-Specific Content requirements by 1 of 2 potential paths:
1) Integrate with OSL existing website (developed by Pollinate)
2) Propose that the vendor will develop their own website for OSL in the "Additional Proposed Offerings" section of the RFP, if vendor could provide this service. This new website would be required to integrate with the mobile app replacement.
1.16 Customer Support: The solution shall provide for player customer support. The solution shall fulfill functional Customer Support requirements by 1 of 2 potential paths:
1) Integrate with OSL existing Customer Support capabilities (homegrown)
2) Propose an alternative Customer Support solution in the "Additional Proposed Solutions" section of the RFP, if vendor could provide this service.
1.17 Apple's App Store and Google Play Compliance: If a mobile app, the solution shall comply with app store requirements, including, but not limited to:
-Providing a method for players to request their account be closed / deleted.
-Specifying which iOS and Android versions are supported by the app. The solution must support multiple versions of the app to account for players that do not automatically upgrade to the latest version.
1.17.1 Regarding closing accounts, the solution shall enable the following:
-Players shall receive an email to confirm they would like to close their account (e.g., automatic strong authentication) -Before closing an account, solution shall check for open activities (e.g., open Second Chance entries) -Once the solution confirms an account should be closed, the account shall be automatically closed (e.g., no manual intervention required by OSL) -OSL operators can manually close accounts if fraud is suspected (e.g., player is quickly scanning a large number of claims)
| 1.18 ADA Compliance: The solution shall comply with ADA Web Content Accessibility Guidelines (WCAG) 2.1: https://wcag.eu/knowledge/guidelines/wcag-2-1-guidelines/ | Multilingual support is a plus. | ||
| Nonfunctional Requirement | "Nice to Have" Nonfunctional Requirement | ||
| 1.19 Security Compliance: The solution shall show proof of compliance with OWASP Guidelines (OWASP MAS Checklist - OWASP Mobile Application Security, https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmas.owasp.org%2Fchecklists%2F&data=05%7C02%7Ckazdanowicz%40deloitte.com%7C27005c1fa9684f129adc08de4f99c2c2%7C36da45f1dd2c4d1faf135abe46b99921%7C0%7C0%7C639035718993191213%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HHQGLmEzZNz07sJiBKXPcrgFuTCJRPPfp22uMyFkwdY%3D&reserved=0). OSL shall have the ability to have the code reviewed by a third party to confirm compliance. | OSL would like to see that the solution holds a valuable security certification (e.g., ISO27001, FedRamp, etc). | ||
| 1.19.1 The mobile application shall prohibit access from devices utilizing VPNs (Virtual Private Networks) and shall prevent logins or transactions if VPN usage is detected. | |||
| Data Management and Reporting | |||
| 2. Comprehensive Data Capabilities: The OSL solution shall provide comprehensive and efficient access to player data, enabling authorized personnel to retrieve, review, and manage player account information in accordance with applicable regulatory standards. The solution must ensure secure, reliable player verification processes to protect user integrity and support responsible gaming practices, while giving the lottery the ability to oversee account lifecycle management, activity monitoring, and compliance reporting. | 2.1 Data Repository: The solution shall include a repository for all player-related administrative information and data related to the solution, which shall be managed by the vendor and accessible, as needed, by specified OSL POCs with configurable access roles. | ||
| 2.1.1 The Data Repository shall include data for existing active players. | Active player data shall be migrated from Akamai. |
*Each active player has an existing Akamai user ID, which will either need to be utilized or mapped to in the Data Repository.
| 2.1.2 The Data Repository shall include data for active second chance entries. |
| 2.1.3 Data retention policies for the Data Repository shall be configurable by OSL. |
| 2.2 Power BI Reports and Lottery Self-Service Analytics: The solution shall provide OSL with access to streamlined, usable reporting and analytics on solution activity via the Data Repository to fulfill specified business needs (including fraud detection). |
The solution shall include a set of standard (“canned”) reports and dashboards, but shall also enable Lottery self-service capabilities to access, curate, analyze, and extract consolidated data and reporting outputs. All reporting shall include consolidated data across all components of the provided solution, including capabilities delivered by partners or subcontractors.
The provider shall deliver a data repository (or equivalent data layer) that enables the Lottery’s existing Microsoft Power BI environment to connect directly for ad hoc reporting and analysis (e.g., via secure, read-only connectivity). The provider shall supply the necessary documentation (data model, data dictionary, refresh/latency expectations, and access controls) to support Lottery-managed report development and ongoing use.
| 2.2.1 BI Reports shall include player scan history, both winning and losing tickets, and Second Chance entry history. |
| 2.2.2 BI reports shall also include device and geolocation data for anonymous players. |
Reference Volumetric Data
| RFP #S-177000-00016166 Functional and Technical Requirements Matrix |
| Relevant Current Lottery Mobile App Volumetric Data |
For reference as Proposers Consider the Size, Scope, and Complexity of their Solution(s):
| Mobile App Measurement Category | Nov-25 | Dec-25 |
| Monthly Active Users | ||
| New Registrations | 8,130 | 24,802 |
| Number of Scanned Tickets | 2,900,606 | 4,900,251 |
| Unique Active Users (e.g., that scanned a ticket) | 15,622 | 23,105 |
| Second Chance Entries | 731,244 | 1,236,733 |
| Volume of Notifications to Players |
This includes all push and in-app messages sent via AirShip, including automated messages: Jackpot notifications, Numbers Are In notifications, promos, giveaways, and notices.
| Messages Sent | 93 | 91 |
| Deliveries | 3,377,847 | 2,869,743 |
| Claims Volume | ||
| In-Person Claims | 6,390 | 8,637 |
| Mail-In Claims | 1,467 | 1,749 |
| Customer Support | ||
| Average Monthly Player Call Volume | 1,500 |
File details come from the government source that posted it. Updated .