Att J - Fit Gap Analysis.xlsx

XLSX spreadsheet 1 MB Posted Dec 2, 2024

Attached to: Hunting and Fishing Electronic Licensing System
Solicitation number: 24-00006
Issued by: Adams County, Asotin County, Benton County, Chelan County, Clallam County, Clark County, Columbia County, Cowlitz County, Douglas County, Ferry County, Franklin County, Garfield County, Grant County, Grays Harbor County, Island County, Jefferson County, King County, Kitsap County, Kittitas County, Klickitat County, Lewis County, Lincoln County, Mason County, Okanogan County, Pacific County, Pend Oreille County, Pierce County, San Juan County, Skagit County, Skamania County, Snohomish County, Spokane County, Stevens County, Thurston County, Wahkiakum County, Walla Walla County, Whatcom County, Whitman County, Yakima County, Asotin City, Clarkston City, Clarkston Heights-Vineland CDP, West Clarkston-Highland CDP, Benton City, Chelan City, Chelan Falls CDP, Clallam Bay CDP, Lewisville CDP, Rock Island City, Pacific Beach CDP, Whidbey Island Station CDP, Mercer Island City, Pacific City, Bainbridge Island City, Kingston CDP, Kitsap Lake CDP, Kittitas City, Klickitat CDP, Okanogan City, Anderson Island CDP, Fort Lewis CDP, Fox Island CDP, Herron Island CDP, Ketron Island CDP, North Fort Lewis CDP, Raft Island CDP, Stevenson City, Hat Island CDP, Lake Stevens City, Snohomish City, Spokane City, Spokane Valley City, Puget Island CDP, Garfield Town, Yakima City, Washington

About this file

Written by GovTribe AI · Dec 9, 2024

This file is a Fit Gap Analysis spreadsheet issued by the Washington Department of Fish and Wildlife (WDFW) for their WILD System electronic licensing project. The document outlines detailed system requirements across multiple categories including vendor requirements, web-based system specifications, customer account management, product catalog functionality, dealer account management, revenue management, sales environment configuration, and drawings/raffles management. The requirements are structured to allow vendors to indicate whether their solution meets each requirement through one of three options: Out of the Box (OOTB), Configurable, or Future Development.

The document emphasizes technical requirements for a robust electronic licensing system that must integrate with state payment processing systems, support nearly 600 dealers, manage customer accounts, handle complex business rules for hunting and fishing licenses, process automated clearing house (ACH) transactions, and maintain 99.99% uptime. Key functionality includes real-time data access, document management, secure payment processing that meets state treasurer requirements, and the ability to conduct over 30 random special hunt drawings and 13 raffle drawings annually. The system must comply with Washington State Office of Financial Management (OFM) standards and Generally Accepted Accounting Principles (GAAP) while maintaining data security and privacy standards set by the state's Office of the Chief Information Officer (OCIO).

View the file

Other files

File	Type	Posted
General Retention Schedule (Common Items).pdf	PDF	Dec 2, 2024
RFP 24-00006 Amd 4.pdf	PDF	Dec 2, 2024
RFP 24-00006 Amd 1.pdf	PDF	Dec 2, 2024
WDFW ELS RFP No. 24-00006 - Sample Contract.pdf	PDF	Dec 2, 2024
RFP 24-00006 Amd 2.pdf	PDF	Dec 2, 2024
WDFW ELS RFP No. 24-00006 - Sample Contract.pdf.crdownload	CRDOWNLOAD file	Dec 2, 2024
RFP 24-00006 ATT A - I.docx	DOCX document	Dec 2, 2024
RFP 24-00006 Amd 3.pdf	PDF	Dec 2, 2024
DFW Records Retention Schedule v.1.11.pdf	PDF	Dec 2, 2024
Att K - Reports.xlsx	XLSX spreadsheet	Dec 2, 2024
WDFW ELS RFP No. 24-00006.pdf	PDF	Dec 2, 2024
RFP 24-00006 Amd 5.pdf	PDF	Dec 2, 2024

Show all 12

On GovTribe

Work with this file

Download the original file
Contacts named in this file
Similar government files
Ask GovTribe AI about this file

Try for free Login

Text version

The file's text, extracted by GovTribe without its formatting.

Fit Gap Analysis Instructions WDFW WILD System Fit Gap Analysis

INSTRUCTIONS:

This workbook comprises 15 worksheets, each corresponding to the requirement categories outlined in Section 5.2.1, “System Requirement Categories,” on page 20 of the RFP. Please analyze and categorize each requirement within this workbook according to its alignment with your solution. This evaluation will assist the Washington Department of Fish and Wildlife (WDFW) in determining how effectively your solution meets our business needs and identifying any additional development work necessary to satisfy all mandatory requirements.

For each requirement, select the option that best describes your solution’s capability:

Out of the Box (OOTB): The requirement is met by the solution as designed.

Configurable: The requirement can be met through configuration.

Future Development: The requirement will need future development to be met.

Only one response may be selected per requirement.

Vendor

	VENDOR
WDFW is seeking an experienced vendor with dedicated, skilled resources, a proven project management methodology, and a superior customer service model to implement a modern, extensible electronic licensing system. WDFW is interested in partnering with a vendor who expects their solution will continue to evolve in response to changes in the market and emerging business needs at WDFW.		OOTB	Configurable	Future Development
	VEN 1.0	General Vendor
	VEN 1.1	The vendor must provide adequate, skilled resources during each phase of the contract (planning, initiation, implementation, deployment, and ongoing maintenance and operations).
	VEN 1.2	The vendor must document: the project methodology; the maintenance and operations methodology; how they will ensure adequate resources are available to correct defects and issues; how they will ensure adequate resources are available to handle statutorily mandated system changes; and what percentage of time the resources are allocated to WDFW. The vendor must propose and document their formal strategy to be negotiated and included in the contract.
	VEN 1.3	The vendor project manager and WDFW project manager must attend regularly scheduled weekly meetings throughout the life of the contract.
	VEN 1.4	The vendor must provide timely notification of staffing changes and document how they will continue to meet contractual obligations.
	VEN 1.5	The vendor must provide a resume and introduce new staff assigned to the project before they begin work on the project.
	VEN 1.6	The vendor must track and document all development hours for enhancements and change requests implemented after go-live and make this information available to WDFW.
	VEN 1.7	The vendor must provide weekly status reports from onboarding through go live.
	VEN 1.8	The vendor must provide release notes and system documentation.
	VEN 1.9	The vendor must work with the current system vendor to create a system transition plan.
	VEN 2.0	Technical Support and Training
	VEN 2.1	The vendor must provide system technical support (Tier 2). (WDFW is responsible for all Tier 1 dealer and customer support.)
	VEN 2.2	The vendor must provide support for all software used to operate the system.
	VEN 2.3	The vendor must provide support for integration with other systems in use by the agency.
	VEN 2.4	The vendor must create and maintain training and support documentation for all users of the system.
	VEN 2.5	The vendor must make all documentation created for system training and support available to users online and kept current throughout the life of the contract.
	VEN 2.6	The vendor tier 2 support staff must record all communications with dealers and WDFW using a ticketing system. Tickets must allow for categorization by issue type.
	VEN 2.7	The vendor must monitor operations, compiling and reporting statistical information applicable to key performance indicators (KPIs) in the Service Level Agreement (SLA).

Web-based System

	WEB-BASED SYSTEM
WDFW requires a vendor-hosted, web-based electronic licensing system that utilizes the most current technologies, meets, or exceeds all WDFW and State of Washington security standards, and can quickly and automatically scale up to meet demand during peak periods.		OOTB	Configurable	Future Development
	WEB 1.0	System Hardware
	WBS 1.1	The vendor must provide all necessary hardware and software used to facilitate the functions of the licensing system unless negotiated otherwise in the contract.
	WEB 2.0	System Infrastructure
	WBS 2.1	The vendor must provide and maintain a secure network in accordance with Washington State Office of the Chief Information Officer (OCIO) Policy No. 141.
	WBS 2.2	The vendor must provide separate environments for development, acceptance testing, pre-production staging, and production.
	WBS 2.3	The vendor must write and maintain technical requirements documentation on system infrastructure to capture system knowledge.
	WBS 2.4	The system must not require any plug-ins to be installed on client machines.
	WBS 2.5	The system must demonstrate proven scalability to withstand increased seasonal load without impacting performance.
	WBS 2.6	Prior to deployment, WDFW must approve the results of a vendor provided load/stress test of the sales system showing at a minimum, duration of the test, number of concurrent users, response time average, and error percentage.
	WBS 2.7	The system must maintain performance expectations as user base, catalog and sales transactions grow over time.
	WBS 2.8	The control center must have an average response time of less than 10 seconds.
	WBS 2.9	The system must provide an infrastructure that prevents reporting and administrative tasks from impacting e-commerce activities.
	WBS 2.10	The system must be available with a 99.99% uptime every month for all users (including customers) 24/7, and 365 days a year, except during scheduled maintenance authorized by WDFW.
	WBS 2.11	The system must be an integrated system, requiring users to authenticate only once per active session.
	WBS 2.12	The system must have redundant infrastructure to provide protection against an outage due to hardware failure, scalability, and the ability to reduce downtime.
	WBS 2.13	The system must be fully operational with all commonly used desktop and mobile browser platforms.
	WBS 2.14	The system must facilitate field validation and restrictions must be applied to all web fields that accept data to maintain data integrity. WDFW must approve these validations and restrictions.
	WBS 2.15	The vendor must not use the content of any cookies or customer meta data collected from the system.
	WBS 2.16	Vendor must provide an adequate and tested disaster recovery plan and ensure completion and validation of hourly backups of both customer accounts and system structure. Normal system operations must resume within 72 hours of a disaster with no data loss before the last backup prior to the disaster.
	WEB 3.0	Data Migration
	WBS 3.1	The vendor must work with WDFW to identify and document the core data to be migrated from existing systems to the new system prior to going live with the new system.
	WBS 3.2	The vendor must provide data migration services from the existing system to the new system, to maintain existing customer accounts and historical data according to the Department of Fish and Wildlife's Records Retention Schedule.
	WBS 3.3	The vendor must manage the data migration process including testing and verification to ensure the data was moved successfully into one central database. This must be done in a secure manner to ensure data integrity and privacy of all system data.
	WBS 3.4	The vendor must maintain a copy of the original database six months after live deployment to the new system for historical reporting analysis to be run against its data.
	WBS 3.5	The vendor must work with WDFW data analysts to verify and validate the integrity and accuracy of the migrated data.
	WBS 3.6	The vendor must correct any data inaccuracies found prior to going live with the new system.
	WBS 3.7	The system must support complete data migration, including all testing of data migration prior to the new system going live.
	WBS 3.8	The system must maintain all identified accounts, business rules, and historical information.
	WBS 3.9	The vendor must ensure converted data behaves the same as newly entered data.
	WEB 4.0	Data Management
	WBS 4.1	The vendor must provide access to the database and all data changes through a master database available to authorized users in real time.
	WBS 4.2	The system must record all data changes and system transactions to a master database viewable by authorized users in real time.
	WBS 4.3	The system must collect, store, retrieve and manage data in databases accessible by authorized ODFW staff.
	WBS 4.4	The system must support storage of and authorized access to all data collected in the system, including data passed into the system through interfaces and processing data to support system functionality.
	WBS 4.5	The system must be capable of logging errors during all system workflows for troubleshooting and administrative review.
	WBS 4.6	The system database must be structured to allow for all data to be extracted using query tools.
	WBS 4.7	The system must support the ability to allow other programs to extract system data using standard tools.
	WBS 4.8	The system must include retention requirements so that a storage end date means the data is no longer available.
	WBS 4.9	The system data must be entered and maintained in a consistent manner, including but not limited to: date format, address format, capitalization, punctuation, and field types.
	WBS 4.10	The system must ensure all data changes should have a date timestamp and user ID of which user entered the change for traceability.
	WBS 4.11	The system must have the ability to maintain history of data for key fields (e.g., address, phone number, date of birth).
	WBS 4.12	The system must capture data change information regardless of method of entry at the database level.
	WBS 4.13	The system must accommodate specialized numbering of system data components sufficient to support identification of each transaction with a unique transaction number and associate it with the related product and customer ID numbers.
	WBS 4.14	The system will maintain a similar naming convention between data elements on the user interface and corresponding data location names in the database even as updates are made to user interface data elements.
	WBS 4.15	The system must support a replica database containing all the data of the master system database.
	WBS 4.16	The system must be in MS-SQL database format.
	WBS 4.17	The system must support a replica database that provides near-real-time data, refreshed every 15 minutes or less.
	WBS 5.0	Document Management
	WBS 5.1	The system must allow authorized users to manage document templates, allow for the creation of new templates, and allow for the modification of existing templates. Document templates must provide standardized document formatting while including information from WILD data.
	WBS 5.2	Printed license documents must be visually identical regardless of sales channels except for temporary discover passes purchased online.
	WBS 5.3	The system must produce a printed license document that displays all current privileges for the current license year, for customer who select customer type, paper customer.
	WBS 5.4	The system must create and record a unique document number for each license document that is produced through the system.
	WBS 5.5	The system must provide a unique document number for each individual document issued through the System.
	WBS 5.6	The system must provide a unique transaction number for all documents purchased in a single transaction.
	WBS 5.7	The printable document format for all system issued documents must include the WDFW logo.
	WBS 5.8	The system must support the use of a barcode scanner to facilitate document management utilizing barcodes on the document template.
	WBS 5.9	The vendor must conduct requirements gathering sessions with WDFW staff to document all required templates and their associated data elements.
	WBS 5.10	The system must generate all documents to meet existing WDFW business rules.
	WBS 5.11	The system must allow authorized users to create new document templates and modify existing templates.
	WBS 5.12	The system must allow each document template to include the complete information required to be printed for each product.
	WBS 5.13	The system must allow authorized users to add additional text, blank space, and signature blocks to established document templates (e.g., a reminder about a change in hunting regulations).
	WBS 5.14	The system must maintain historical versioning of all document templates.
	WBS 5.15	The system must allow authorized users to limit the number of reprints and establish the period within which a reprint can be processed.
	WBS 5.16	The system must allow for the prevention of a reprint if a tag or report card has been used or a privilege has expired.
	WBS 6.0	System Administrative Tool
	WBS 6.1	The system must provide a web-based, back-office tool, known as “Control Center”, to manage system data and system functionality.
	WBS 6.2	The system must allow authorized users to create, edit and deactivate internal user accounts and user groups.
	WBS 6.3	The system must allow authorized users to set permission levels by individual user and/or user group. Permissions must be available for: viewing, editing, creating, and maintaining system data down to the data field or data field category level.
	WBS 6.4	The system's users must be uniquely identifiable throughout the system.
	WBS 6.5	The system must allow authorized users the ability to manage all system user passwords and all system users must be able to reset their own passwords.
	WBS 6.6	The system must require a user to re-authenticate after a specified amount of time has lapsed.
	WBS 6.7	The system must provide back-office search functionality for all components of the system.
	WBS 6.8	During development, vendor must work with WDFW to define technical requirements for system search & filtering.
	WBS 6.9	The system must support a “super user” role that has ALL permissions available in the system.
	WBS 6.10	The system must provide a means for administrators using back-office tools to scan a barcode or QR code.
	WBS 6.11	The system must provide a mechanism for editing system wide configuration settings through the user interface.

Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1 Check Box 1

Customer Account

	CUSTOMER ACCOUNT
WDFW desires an intuitive customer account module that can be used by customers, dealers, and WDFW staff. This includes customer account creation and management, customer communication, veteran, active-duty military, and disability status management, special use permit eligibility and issuance, hunter education certifications, and administrative tools.		OOTB	Configurable	Future Development
	CUS 1.0	Customer Account Creation
	CUS 1.1	The system must provide a wizard to guide new customers through each step of the account creation process.
	CUS 1.2	The system must allow the customer to enter a non-US address.
	CUS 1.3	The system must prevent a user from choosing a username which already exists in the system.
	CUS 1.4	The system must prevent a user from choosing non-alpha numeric characters in their username.
	CUS 1.5	The system must prevent a user from changing their username once their username has been created.
	CUS 1.6	The system must provide a mechanism for a WDFW user to reset a customer's password
	CUS 1.7	The system must prevent a user from changing their username to an existing username
	CUS 1.8	The system must provide a mechanism for certain user types (customers under the age of 15, non-US citizens, etc.) to create a new customer account without providing a Social Security number
	CUS 1.9	The system must require a Social Security number for all customers aged 15 and older if they have been issued a Social Security number.
	CUS 1.10	The system must send new customers an email with instructions on how to activate their account when their customer account was created for them by a WDFW, call center, or dealer user.
	CUS 1.11	The system must create a unique numeric customer identifier known as the WILD ID.
	CUS 1.12	The system must migrate existing active customer WILD IDs and preserve this ID for the customer in the new system during the migration process.
	CUS 1.13	The system must use an incrementing unique integer to create WILD IDs for new customers post data migration.
	CUS 1.14	The system must generate a new WILD ID only after an account is confirmed.
	CUS 2.0	Customer Account Management
	CUS 2.1	The system must support multiple customer types such as resident, non-resident, youth, senior, and disabled.
	CUS 2.2	The system must automatically determine a customer's residency status through a calculation of the customer's attributes such as physical address, length of time residing in the state of Washington, age, and military affiliation.
	CUS 2.3	The system must present the lowest price available to the customer based on their residency, disability, and military status.
	CUS 2.4	The system must clearly display a customer's residency status when a customer profile is being viewed by any authorized user including customers.
	CUS 2.5	The system must indicate when a customer account requires the customer to verify/update their profile when an authorized user, or customer accesses the account.
	CUS 2.6	The system must present to the customer, whose account has been set as requiring verification, with their customer demographic information upon next login or access by an authorized user and require the customer to attest to the accuracy of the displayed information prior to completing a sales transaction.
	CUS 2.7	The system must allow authorized WDFW administrators to configure the time interval a customer account can exist before the customer must verify their demographic information on their next login.
	CUS 2.8	The system must provide functionality to identify and prevent duplicate customer accounts during the account creation.
	CUS 2.9	The system must provide field validation on all data fields to maintain the quality of customer data.
	CUS 2.10	The system must validate all fields during the customer enrollment process and prevent a customer from proceeding to the next step of the enrollment process until validation is successful.
	CUS 2.11	The system must validate all fields during the customer edit process and prevent a customer from saving the edits to a customer account until validation is successful.
	CUS 2.12	The system must collect, and store all required demographic information in the customer account. Customer account data fields must be defined during data migration and technical requirements gathering.
	CUS 2.13	The system must allow customers to opt in/out of marketing emails and text messages from WDFW.
	CUS 2.14	The system must not allow customers to opt out of transactional emails and text messages regardless of their marking communications designation (e.g., sales receipt, submission confirmation, multi-factor authentication, and direct communication from WDFW support staff).
	CUS 2.15	The system must provide the following hunter education fields: certification number, certification type, certification date, expiration date, state issued, status (active or inactive)
	CUS 2.16	Hunter education certification types must include basic, master hunter, archery, trapping, wildlife control operator (WCO), out of state, southwest goose identification, hunter education deferral.
	CUS 2.17	The system must allow authorized users to apply a Southwest Canada Goose hunt authorization to the customer account. The application of the hunt authorization must allow the customer to purchase the Southwest Canada Goose report card.
	CUS 2.18	The system must make catalog items available based on customer disability statuses.
	CUS 2.19	The system must display disability related products to all customers regardless of disability status but only allow customers with a disability status to proceed with a purchase from this subset of products. A customer without a disability status must be prevented from putting a disability related product in the shopping cart.
	CUS 2.20	The system must prevent a customer without a disability status from putting a disability related product in the shopping cart.
	CUS 2.21	The system must recognize and provide free license items for legacy “lifetime privilege” customers who were selected in previous “lifetime” drawings (these drawings are no longer allowed). Lifetime licenses include combination fishing license, Puget Sound crab endorsement, combination big game license (deer, elk, bear, cougar), small game license with one turkey tag, Western Washington pheasant, and migratory bird authorization.
	CUS 2.22	The system shall migrate all existing lifetime license customers to the new WILD system keeping their lifetime license designation as active.
	CUS 2.23	The system must charge a dealer fee when “lifetime” licenses are sold.
	CUS 2.24	The system must provide a mechanism for a customer to create a username and password to use when logging in to the system.
	CUS 2.25	The system must provide a mechanism for a customer to log in to the system using a multifactor authentication method that requires a unique ID (WILD ID, Social Security number, last name, and birth date) for web and mobile applications.
	CUS 2.26	The system must provide a mechanism for a customer to reset their password
	CUS 3.0	Customer Communication
	CUS 3.1	The system must allow for the entry, tracking and management of customer communications through a ticketing type system.
	CUS 3.2	The system must provide granular permissions for creating, editing, and viewing ticket content and for the management of ticketing workflows.
	CUS 3.3	The system must allow authorized users to create customer ticket categories and assign a category to a ticket.
	CUS 3.4	The system must allow authorized users to assign a status to a customer ticket, including open, assigned, escalated, and closed.
	CUS 3.5	The system must default all tickets from WDFW to a customer as being hidden from customer view.
	CUS 3.6	The system must provide authorized WDFW users the ability to restrict or grant viewing of tickets and notes entered in the ticketing system.
	CUS 3.7	The System must provide a mechanism to record the customer WILD ID and customer name, date, and time the ticket was opened, the date and time the ticket was closed, the user that opened the ticket, the user that closed the ticket, the type of communication, changes made to the original ticket, and associate communications within the ticket.
	CUS 3.8	The system must allow authorized WDFW users to add notes to a customer account
	CUS 4.0	Disability Status and Special Use Permits
	CUS 4.1	The system must provide functionality to manage the process of disability statuses in customer accounts. Statuses include disabled veteran, disabled veteran over 65, permanently confined to a wheelchair, developmentally disabled, legally blind, physically disabled, disabled hunter, blind hunter, upper extremity disability, and lower extremity disability.
	CUS 4.2	Statuses that allow reduced fees are disabled veteran, disabled veteran over 65, permanently confined to a wheelchair, developmentally disabled, and legally blind.
	CUS 4.3	The system must provide functionality to manage the process for Special Use Permit (SUP) applications & types in customer accounts. Types include crossbow, shoot from motor vehicle, scope, alternate casting gear, other (Other status will be available to authorized users on a case-by-case basis).
	CUS 4.4	The SUP designation in the customer account must include an optional expiration date.
	CUS 4.5	The system must allow multiple SUP types to be entered in a customer account.
	CUS 5.0	Hunter Education Certifications
	CUS 5.1	The system must provide a workflow process to manage each hunter education certification type according to the individual certification configuration rules.
	CUS 5.2	The system must provide granular permissions to create, edit, delete and view of hunter education certification data and associated workflows.
	CUS 5.3	The system must restrict customers from entering the hunter education certification data.
	CUS 6.0	Merge Tool
	CUS 6.1	The system must have the ability to merge multiple customer accounts for the same person.
	CUS 6.2	The system must allow authorized users to designate a customer source account and a customer destination account as part of the merge process.
	CUS 6.3	The system must allow authorized users to simultaneously view the customer source account information and the customer destination account information as part of the merge process.
	CUS 6.4	The system must provide a mechanism for authorized WDFW users to designate which fields should be merged from a customer source account to the customer destination account.
	CUS 6.5	The system must provide a confirmation message to an authorized user prior to merging two customer accounts and highlight which customer data fields will be merged.
	CUS 6.6	The system must automatically set the customer source account as inactive after the merge process has been completed.
	CUS 6.7	The system must provide a mechanism to search for customer destination and source accounts.
	CUS 6.8	The system must provide functionality that allows authorized users to review merge history and unmerge accounts.
	CUS 6.9	The system must produce a history of a customer merge that is viewable in the customer profile information for both the source and destination accounts that have been merged.
	CUS 6.10	The system must denote in the database that a customer account has been merged allowing for the rapid creation of a merge history report.
	CUS 6.11	The system must allow the customer to reprint their license document with all non-conflicting license privileges on the newly merged account.
	CUS 6.12	The system must send the customer a notification that their accounts have been merged.
	CUS 6.13	The system must require the customer to verify the demographics information in the destination account after the merging of accounts has occurred.

Product Catalog

	PRODUCT CATALOG
At the core of the licensing system is WDFW’s extensive 286-item product catalog. WDFW requires robust e-commerce catalog functionality that will allow WDFW system administrators to create and maintain a variety of interdependent and dependent license products.		OOTB	Configurable	Future Development
	CAT 1.0	Catalog Configuration
	CAT 1.1	The system must allow for the creation, management, and assignment of pre-defined business rules to catalog items. Business rules are defined by RCW, WAC and WDFW policy.
	CAT 1.2	The system must allow categorization of product items for but not limited to: sales display, reporting, and for the ease of catalog management.
	CAT 1.3	The system must allow the management of products by and/or across license years.
	CAT 1.4	The system must support the association of catalog items to a license year.
	CAT 1.5	The system must provide the ability to designate a product as being a seasonal product associated with a license season.
	CAT 1.6	The system must provide the ability to designate a product as being a non-seasonal product independent of a license season.
	CAT 1.7	The system must provide the ability to manage products by category and sub-category.
	CAT 1.8	The system must require all products to have a product category.
	CAT 1.9	The system must require all products to have a product type.
	CAT 1.10	The system must allow for the management of a new or existing product name, product description, product tagline, print template assignment, product type, species, hunt series, and raffle series.
	CAT 1.11	The system must allow authorized users to select and assign a product code for new products instead of a system-generated code.
	CAT 1.12	The system must provide the ability to set a season start date for a product during product creation or editing.
	CAT 1.13	The system must provide the ability to set a season end date for a product during product creation or editing.
	CAT 1.14	The system must provide the ability to set a purchase start date for a product during product creation or editing.
	CAT 1.15	The system must provide the ability to set a purchase end date for a product during product creation or editing.
	CAT 1.16	The system must require all products with a product type of 'Transport Tag' or 'Special Hunt' to have a species category.
	CAT 1.17	The system must allow authorized WDFW users to create products that allow the customer to select the privilege's 'valid from' start date at the time of purchase.
	CAT 1.18	The system must prevent a customer or dealer from selecting overlapping dates for the same products that allow customer selection of 'valid from' start dates.
	CAT 1.19	The system must provide the ability to establish a parent/child relationship between catalog items.
	CAT 1.20	The system must provide the ability to establish an existing product as a pre-requisite which must be purchased prior to the purchase of the current product.
	CAT 1.21	The system must provide the ability to establish an existing product as a conflicting product which will disallow the purchase of the product if the conflicting product has already been purchased.
	CAT 1.22	The system must provide the ability to display a suggested product which will appear to the customer as an optional item for purchase when the customer adds the prerequisite product to their shopping cart.
	CAT 1.23	The system must provide the ability to designate an included product which will automatically be added to a customer's shopping cart when the prerequisite product(s) are added
	CAT 1.24	The system must allow products to be restricted to sales channels/dealer types.
	CAT 1.25	The system must allow for the designation of the following sales channels from which a product can be purchased: dealer, internet, phone, WDFW office, WDFW headquarters, and call center.
	CAT 1.26	The system must make available the following customer pricing categories: resident, non-resident, youth, resident disabled, non-resident disabled veteran, and resident senior.
	CAT 1.27	The system must allow users to sort the catalog by season, category, and/or product type.
	CAT 1.28	The system must allow multiple license years to be available for purchase at the same time.
	CAT 1.29	The system must automatically set a product to 'inactive' by default when a product is initially created.
	CAT 1.30	The system must provide a mechanism to allow for a product to be exempt from a transaction fee (e.g., donations and hunter education deferral products).
	CAT 1.31	The system must limit the number of duplicates allowed per customer for a product.
	CAT 1.32	The system must provide a mechanism to allow for the association of a product as a post drawing item.
	CAT 2.0	Catalog Search Tool
	CAT 2.1	The system must allow authorized users to search and filter products within the product catalog at a minimum by name, category, license year, product code, active and inactive status, and customer type.
	CAT 2.2	The system must provide a basic product search mechanism allowing the authorized user to enter a search term which will produce a list of products for which the search term matches one or both of the following product fields: product code, product name.
	CAT 2.3	The system must provide an advanced product search mechanism allowing the authorized user to search for a product on one or more of the following fields: product code, product name, product category, product type, season.
	CAT 2.4	The system must provide an advanced product search mechanism allowing the authorized user to filter product search results based on the active or inactive status of a product record.
	CAT 2.5	The system must allow dealers and customers to sort products by season, type of product (license, tag, etc.) and category (hunting, fishing, parking passes, etc.).
	CAT 2.6	The system must allow dealers and customers to set their default product search, which should remain in effect unless reset by the dealer location or customer.
	CAT 3.0	Catalog Display
	CAT 3.1	The system shall only display catalog items based on customer eligibility or item availability driven by the product catalog. Criteria must include but not be limited to age, residency, purchase prerequisites, test results (with a passing score), and hunter education requirements.
	CAT 3.2	The system must display all catalog items within the saleable date range and available through the sales channel to all customers regardless of the customer's eligibility to purchase the product.
	CAT 3.3	The system must identify any products the customer is not eligible to purchase as unavailable and provide an explanation as to why.

Dealer Account

	DEALER ACCOUNT
The system must include a dealer account module that allows WDFW to manage nearly 600 dealers’ demographics and user access.		OOTB	Configurable	Future Development
	DLR 1.0	Dealer Account
	DLR 1.1	The system must migrate existing active dealer accounts and preserve this ID for the dealers in the new system during the migration process.
	DLR 1.2	The system must not migrate existing usernames or passwords for active dealers.
	DLR 1.3	The system must provide authorized users the ability to create and edit dealer demographics.
	DLR 1.4	Dealer account data fields must be defined during data migration and technical requirements gathering.
	DLR 1.5	The system must provide the ability to manage license dealers by dealer location type.
	DLR 1.6	The system must categorize dealers by location type with the following values: license dealer, corporation, WDFW headquarters, WDFW office, phone, limited dealers, trade show, call center, and internet
	DLR 1.7	The system must include the ability to assign a business type to a dealer location, including but not limited to: Business types include the following values: auto licensing, chamber of commerce, convenience store, department store, discount store, feed supply, firearm store, general store, grocery store, hardware store, marine supply, military exchange, outdoor store, pawn store, pharmacy, resort, sporting goods store, state agency, discover pass, and charter/guide stamps.
	DLR 1.8	The system must allow for the grouping of dealer accounts under a corporation.
	DLR 1.9	The system must provide a mechanism for the association of a dealer with a corporation during dealer account creation or dealer account editing.
	DLR 1.10	The system must allow the creation and management of a dealer grouping for corporate ACH invoicing.
	DLR 1.11	The system must allow authorized users to restrict specific product items or categories from being sold at a dealer location.
	DLR 1.12	The system must provide a mechanism for authorized users to indicate which customer account sale types are allowed at each dealer location during creation or editing of dealer profiles. Customer account sale types include hot key, limited, and full customer accounts.
	DLR 1.13	The system must provide a mechanism for preventing the sale of hot key items through all sales channels except dealer locations, WDFW headquarters, and regional offices.
	DLR 1.14	The system must designate a role-based permission to allow WDFW users to create a dealer.
	DLR 1.15	The system must designate a role-based permission to allow WDFW users to edit a dealer.
	DLR 1.16	The system must designate a role-based permission to allow WDFW users to view a dealer's financial information.
	DLR 1.17	The system must designate a role-based permission to allow WDFW users to edit a dealer's financial information
	DLR 1.18	The system must designate a role-based permission to allow WDFW users to create a dealer user account (administrators and clerks).
	DLR 1.19	The system must designate a role-based permission to allow WDFW users to edit a dealer user account (administrators and clerks).
	DLR 1.20	The system must designate a role-based permission to allow WDFW users to create and edit financial reports users.
	DLR 1.21	The system must allow WDFW authorized users the ability to place a dealer on temporary hold to restrict the ability to sell licenses.
	DLR 1.22	The system must allow WDFW authorized users the ability to place a dealer or corporation on temporary ACH hold.
	DLR 1.23	The system must designate a role-based permission to allow a dealer administrator to manage administrator and clerk users for their dealership.
	DLR 1.24	The system must designate a role-based permission to allow a dealer administrator to create a new dealer administrator user for their location.
	DLR 1.25	The system must designate a role-based permission to allow a dealer administrator to create a new dealer clerk user for their location.
	DLR 1.26	The system must designate a role-based permission to allow a dealer administrator to inactivate a dealer clerk or administrator user for their location.
	DLR 1.27	The system must provide dealer users the ability to log in to their accounts regardless of what product categories are made sellable for a dealership
	DLR 1.28	The system must provide a mechanism allowing dealer users to view all transactions issued at their dealer location.
	DLR 1.29	The system must prevent a dealer user from viewing transactions issued at dealer locations other than their own.
	DLR 1.30	The system must prevent a dealer from being able to cancel a transaction after 60 minutes from initial issuance
	DLR 1.31	They system must prevent a dealer from being able to cancel a transaction that was issued by another dealer
	DLR 1.32	The system must prevent a dealer from being able to duplicate products within 60 minutes of the initial sale of the items.
	DLR 1.33	The system must prevent a dealer user from issuing license items for two different license years in the same transaction.
	DLR 1.34	The system must allow dealer users to access and print agency authorized dealer sales reports.
	DLR 1.35	The system must allow dealer users to access dealer sales reports through a web-based portal.
	DLR 1.36	The system must allow corporate users to view information for all dealers under their corporation
	DLR 1.37	The system must generate a corporate weekly billing invoice that includes all dealer locations under the corporation.
	DLR 1.38	The system must generate a dealer weekly billing invoice for each dealer location not associated with a corporation.
	DLR 1.39	The system must provide access for corporate users to log in and run financial reports for all dealer locations under their corporation.
	DLR 1.40	The system must mask or hide the Social Security number as a dealer is entering a customer's social security number during customer account creation, or when a business rule is requiring the entry of a customer's Social Security number on an existing account.
	DLR 1.41	The system must provide a basic dealer search mechanism that allows WDFW users to enter a search term that will produce a list of dealers for which the search term matches one more of the following fields: dealer ID, business name, corporation.
	DLR 1.42	The system must provide an advanced dealer search mechanism that allows WDFW users to search for a dealer using one or more of the following fields: dealer ID, business name, corporation, managing dealer, dealer type, business type, city, county, account representative.
	DLR 1.43	The system must provide an advanced dealer search mechanism allows WDFW users to filter dealer search results based on the active or inactive status of a dealer record.
	DLR 2.0	Dealer Communication
	DLR 2.1	The system must allow dealer users to send direct messages to WDFW.
	DLR 2.2	The system must store all communications between dealer users and WDFW.

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 Dec 9, 2024.