Functional Requirements Response Table

Colorado DRIVES – Functional Requirements – Response Tables

Driver Licensing

Req. ID Collect Customer Information

Noncommercial Driver Credential Application

DL 1

The system should allow for either the manual or electronic submission and/or intake of a driver customer-completed application for new or renewal of a driver credential.

DL 2

The system should allow for either the manual or the electronic submission and/or intake of a driver customer-completed request for a name change, change of address or other applicable information changes to the driver credential.

Commercial Driver Credential Application

DL 3

The system should allow for the manual or the electronic submission and/or intake of a commercial driver customercompleted application for new or renewal of a driver credential.

DL 4

The system should allow for the manual or the electronic submission and/or intake of a commercial driver customercompleted request for a name change, change of address or other applicable information changes to the driver credential.

ID Card Credential Application

DL 5

The system should allow for either the manual or the electronic submission and/or intake of a customer-completed application for new or renewal of an identification credential.

DL 6

The system should allow for either the manual or the electronic submission and/or intake of a customer-completed request for a name change, change of address or other applicable information changes to an identification credential.

General

Req. ID Collect Customer Information

DL 7

DL 8

DL 9

DL 10

DL 11

The system should support the ability for DMV agents to retrieve all information including documents that have been previously scanned and captured in association with a driver/applicant.

The system should have the ability to capture security questions for customers calling DMV agents for service over the phone.

The system should have the ability to track employee training and certifications (optional requirement).

The system should have a report for tracking each transaction and the type of transaction.

The system should capture and track the type of submission

(manual or electronic) and who initiated the transaction

(employee or customer).

Req. ID Process Information and Conduct Tests

Apply for Credential

DL 12

The system should provide the ability to record and track beginner or teen drivers in order to certify education credentials to receive a learners permit or provisional license.

DL 13

The system should provide the ability to process applications and issue credentials including, but not limited to, the following types: non-driver identification, noncommercial, commercial, learner’s permit, motorcycle, endorsements, etc.


DL 14

DL 15

DL 16

The system should provide the current checklist of documents that the customer is required to provide based on the type of service request.

The system should provide the ability to flag endorsement expirations (e.g., Hazmat)

The system should support the Real ID and non-Real ID credentialing guidelines.

DL 17

DL 18

The system should provide the ability to suggest possible fraud situations based on information received and background and internal checks performed (e.g., multiple credentials for the same person).

System should comply with all applicable federal (e.g., CDL,

NDR, Real ID Act), compact (DLA/DLC-one license one person/surrender of Out of State license), and State laws.

DL 19

Receive and electronically record out-of-state license surrender and transmit to former JOR (Jurisdiction of Record). In-State

Surrender: Receive and electronically record/transmit the surrender of a CO license from a new JOR (Jurisdiction of

Record).

Create Customer Record

DL 20

The system should automatically assign a unique customer identifier during the process of adding a new customer.

DL 21

The system should support maintaining person-based customer

“records” or profiles that contain attributes such as, but not limited to: Legal name, alias names, Street Address, Mailing

Address, date of birth (DOB), eligibility (e.g., program, military, plate), exemptions, etc.


DL 22

DL 23

DL 24

DL 25

DL 26

DL 27

DL 28

DL 29

The system should support an automated process to check a driver’s record from another state and transfer compliance, revocation, medical information from the other state to the CO driver record. (for example, existing of DWI and Interlock requirements)

The system should support maintaining business-based customer profiles. A business customer profile may contain attributes such as, but not limited to: Legal name of the business, a DBA name, one or more location identities, Social

Security Number or Federal Employer Identification Number, or other identifiers, Mailing address, Contact information, Type of organization (LLC, corporation, etc.), identification information for owners, officers, partners, exemptions, etc.

The system should have user-defined rules to identify the mandatory data elements based on the function (e.g., driver license, titles and registration, driver services actions

(penalties/sanctions)).

The system should be able to record the role that a customer has in a transaction.

The system should provide the ability to enter detailed information about a customer including preferred methods of communication, general commentary, and alerts.

The system should provide the ability to store and/or associate digital images from the credentialing system.

The system should provide the ability to capture, store, and associate electronic images of supporting documentation with the customer record.

The system should provide the ability to relate individual customer accounts, customer roles (e.g., Power of Attorney, vehicle owner, business owner) in order to provide a consolidated view of all relationships a customer may have with

DMV.


DL 30

DL 31

The system should provide the ability to modify an in-process transaction without having to void/start over.

The system should provide the ability to allow a partial transaction for update/completion at a later date.

DL 32

The system should provide the ability to deny an application and produce an appeal notice letter.

Update Customer Information

DL 33

The system should provide the ability to change a customer’s name, address, etc. at the request of the customer, including updates and changes to all of the person’s roles.

DL 34

The system should allow the uploading of supporting documents, ie: marriage license, divorce decree, court ordered name change. This functionality should allow for upload of documents prior to a customer arriving at a DL office for service, and allow customers to provide additional supporting documentation after a DL office visit.

DL 35

DL 36

DL 37

DL 38

DL 39

DL 40

The system should allow the customer to request a change name, address, etc. online, via an electronic submission.

The system should provide the ability to enter detailed notes about a customer including telephone, e-mail, and paper correspondence information.

The system should support interfaces from internal and external sources for the purpose of adding, modifying, or authenticating customer data (e.g., law enforcement, U.S. Post Office).

The system should provide an alert when data authentication detects an error (e.g., using an address that does not exist).

The system should allow a customer account to be merged with another (as an alias) customer account to create a single view.

The system should be able to assist with locating a previous record and capability to combine records if necessary.


DL 41

DL 42

DL 43

DL 44

DL 45

DL 46

DL 47

The system should allow merged customer accounts to be separated, by an authorized user with the proper system security role

The system should provide the ability to maintain a history (and a copy of the record) of previous records that have been merged.

Accessing the old record should include a note that it has been merged and to what record and that the information cannot be changed in the previous record. Finally, the system should update the PDPS pointers for the new record created as a result of the merge.

The system should record a complete audit trail, including record version, of the customer record of transactions, including, but not limited to, the identity of the DMV employee completing a transaction or viewing an account, along with a time/date stamp per activity/transaction (e.g. terminal ids, host name, IP address).

All business transactions on driver records, system tables, and peripheral system records (both inquiry and update) should include audit data such as user, location, update timestamp and any system generated changes, what was changed, as well as records viewed. There should be facilities to retrieve this audit information via real-time reports and data mining applications.

The system should capture activity logs that identify the type of transaction, user performing the transaction, records and fields accessed, frequency of access, type of access being performed

(e.g., creating, updating, voiding, printing, viewing).

The system should have the ability to capture information for a hearing and/or visually impaired applicant.

The system should identify the DMV agent and the location that issued an endorsement (e.g., motorcycle, etc.)


DL 48

DL 49

The system should provide the ability for the agent to check the status of a driver’s license endorsement, driver’s license, and eligibility conditions.

The system should provide the ability for a customer with proper access credentials to check the status of their own driver’s license endorsement, driver’s license, and eligibility conditions while in a DLO.

DL 50

DL 51

DL 52

The system should provide the ability to issue a flag that alerts the DMV agent that a CDL driver is downgrading their license status and requires application of retesting rules.

The system should have the ability to record voter registration information and transmit to Secretary of State and county elections offices.

The system should have the ability to receive voter registration information from the Secretary of State.

DL 53

DL 54

The system should have the ability to receive Death record information from an external source (e.g., SSA).

The system should allow for an authorized user to enter a confidential address for a customer that requires one (e.g., domestic abuse program, identity theft victims).

Inquire Customer Information

DL 55

The system should support searches on customer information using configurable elements such as (but not limited to) DL number, plate, title number, birth date, name, business name,

DBA, passport number, SSN, ITIN, and other identifiers.

DL 56

The system should provide the ability to inquire on a customer’s previous name(s) and return all records associated with the customer.


DL 57

DL 58

DL 69

DL 60

The system should support inquiries/searches for customer records including a “Soundex search” capability for customer records that are close to the given name and other demographics. (“Soundex” is a phonetic algorithm for indexing names by sound, as pronounced in English.)

The system should support inquiries/searches for customer records including using “wildcard” characters or Boolean searches.

The system should be able to determine if the applicant is compliant with the requirements related to Colorado Road and

Community Safety Act (CRS 42-2-505) regarding individuals in violation of federal immigration laws (e.g., current with State income tax requirements).

The system should allow public DMV customers the ability to access their limited DMV information through a validation or log-in process in order to conduct certain business transactions and self-initiated inquiries via the internet and/or web interface.

Compliance

DL 61

The system should support the use of state and federal sources to standardize and validate customer information such as business names, individual identities, addresses, SSN, etc. (e.g.,

AAMVA, SSOLV, PDPS, ICE/SAVE, Real ID Act checks).

DL 62

DL 63

DL 64

The system should have the capability to utilize the SAVE Web system on all initial intake for DMV locations.

The system should support the ability to maintain and track accrued penalties for customers (such as points, etc.) based on business rules for a given date and flag the DMV agent when the customer has penalties on their record or they are out of compliance.

The system should provide the ability to receive, capture, and record compliance documents and information from the courts

(e.g., clear a court action).


DL 65

DL 66

DL 67

DL 68

DL 69

DL 70

DL 71

DL 72

DL 73

DL 74

The system should be able to check customer compliance rules as they relate to the title, credentialing, sanctioning and registration processes and define work flows based on the results.

The system should automatically determine which compliance checks are required based on the type of service request, retrieve and verify compliance data without the user re-entering, including for medical and persons with disability services

The system should accommodate the ability to support alternative Driver’s License renewal solutions (such as written or vision testing) to facilitate self-service renewal.

The system should provide the ability to access data in both online and batch process environments, and create notification of compliance violations.

The compliance module should be a self-contained combination of data and methods.

The system should track and provide a report of all the types of documents produced for a user-specified time period, along with the employee’s user ID.

The system should allow any pending information for future transaction completions, and clearly indicate that the status is pending.

The system should provide the ability to define business rules and/or utilize a rules engine that can establish and ‘clear’ the compliance.

The system should have the ability to run a background rules compliance edit and flag any exceptions for processing, both as a real-time and a batch process

The system should provide the ability for authorized users to update business rules.


DL 75

DL 76

DL 77

DL 78

DL 79

DL 80

DL 81

DL 82

DL 83

DL 84

DL 85

The system should document business rule changes, capturing before and after values, date, time, reason for the change, and user IDs (allowing for segregation of duties of 2 or 3 authorized users involved in the process).

The system should allow authorized users to perform a real-time update of any compliance information consistent with business rules defined.

The system should require an authorized user performing a realtime update to document the reason for the update and attach scanned supporting documentation.

The system should log all real-time updates and supervisory overrides to compliance status including user ID, date, time, supervisor ID and reason for override values.

The system should maintain statistics of non-compliance checks for use in operational and management decisions.

The system should read compliance information and generate appropriate notification of non-compliance and remediation required when creating invitations to renew driver’s licenses.

The system should provide the ability to add external identifiers to customer records.

The system should make the customer aware of any privilege or compliance issues during interaction with the DMV.

The system should automatically begin conducting checks with

PDPS, CDLIS, and SSOLV with the initiation of an application whether via the Web site or by an Agent online, including for persons with disability and medical issues

The system should provide the ability for compliance status and corrective actions to be printed.

The system should provide for the association of customer account data with customer specific compliance data using unique customer identifier.


DL 86

The system should provide the ability to access compliance information directly or through real-time interfaces with external data sources.

Stops and Overrides

DL 87

The system should provide the ability to stop transactions or other processes (e.g., exam) from being completed if compliance violations are found during processing

DL 88

DL 89

DL 90

DL 91

DL 92

DL 93

DL 94

The system should be able to identify departmental actions, unpaid penalties, etc, to prevent the system (employee) from producing a document.

The system should have a hard stop if the customer has an investigation alert.

The system should provide for supervisory override capability to allow authorized personnel to process a transaction when the system returns a noncompliant status.

The system should have hard stops as in DLS. But should also allow overrides by management when necessary.

The system should provide authorized user access to override/update system-generated denials for issuing the license by an authorized user with the proper system security role.

The system should provide the ability to record notes explaining the actions and decisions regarding a transaction, and this should be accessible to all DMV staff.

The system should log overrides and identify the authorized user, date/time, location and reason for override (network information such as: IP address, host name, etc).

Address Matching

DL 95

The system should provide the ability to conduct an online check to verify if there are other individuals living at the same address as the customer.


Archiving

DL 96

The system should archive all updates to all driver license table records.

Credential Processing

DL 97

The system should provide the ability to calculate and store an expiration date on a credential as defined by business rules.

DL 98

DL 99

DL 100

The system should not permit the issuance of a license where one or more suspensions or withdrawals are active in any internal or external jurisdiction (e.g., National Driver Registry).

The system should have the capability to capture state- and county-specific credentialing historical information, as needed through interstate reciprocity and FMCSA regulations.

The system should provide the ability for a customer to have either a Colorado ID or a Driver’s License.

DL 101

DL 102

DL 103

The system should provide the ability to create an ID/Driver

License card utilizing previously captured customer and credential information.

The system should allow an agent with appropriate access to restore an individual’s driver’s license privilege.

The system should maintain information on a driver’s license application.

Commercial Driver (CDL)

DL 104

DL 105

The system should have an end of day automatic auditing of all

Driver License documents.

The system should produce all State forms and allow electronic signatures to send to Document preservation/microfilming.

DL 106

The system should include daily, weekly, monthly, and yearly accounting reports. The system should have the ability to allow reconciliation of all transactions.


DL 107

DL 108

DL 109

DL 110

DL 111

DL 112

DL 113

DL 114

DL 115

DL 116

DL 117

DL 118

The system should display which location supplied Hazmat application.

The system should display status of Hazmat application and date approved. The system should be able to transfer and intake an out-of-state Hazmat endorsement.

The system should alert the authorized user as to how many years remain on Hazmat background check.

The system should be able to accept and link scanned documents submitted for Hazmat application which then should be retrievable by the DMV agent.

The system should provide multiple driver contact information.

The system should provide means of electronically capturing the citation data avoiding manual entry.

The system should provide an audit transaction log of users that have viewed or touched a customer record including, but not limited to, date/time and the action performed.

The system should not allow a commercial driver to obtain both a valid CDL and ID card.

The system should provide documentation to driver and electronically file in the system that driver surrendered.

The system should be able to receive and store DOT medical information.

The system should automatically send an add (UA) message to

CDLIS when a CDL permit is issued and no pointer at CDLIS exists.

The system should automatically send an update (UC) message to CDLIS when there is an existing Colorado pointer at CDLIS and a CDL has been issued and demographic information has changed.


DL 119

DL 120

DL 121

DL 122

DL 123

DL 124

The system should automatically initiate a Change State of

Record (UD) message when any type of Colorado license is issued and there is an existing pointer at CDLIS from another state.

The system should allow an individual to hold a CDL and CDL learners permit(s) at the same time.

The system should allow an individual to hold a regular license and multiple CDL Learners permits at the same time.

The system should not allow issuing a CDL or CDL Learners permit unless there is a valid DOT medical on file.

The system should not allow issuing a CDL permit without a valid Regular Driver’s License on file.

System should not allow issuing a CDL permit or CDL unless all required CDL knowledge and Skills tests have been taken and passed.

DL 125

DL 126

DL 127

System should not allow adding CDL endorsements to a CDL permit or CDL unless all required CDL knowledge and skills tests have been taken and passed.

System should allow the examiner to be able to initiate the 10

Year History checks when required.

The system should have a solution to manually add, change, delete pointers at CDLIS and also do a Change State of Record.

Data Transfer

DL 128

The system should support real-time information exchanges to establish data cross matching programs with other State agencies.

DL 129

The system should provide the ability to associate an ID card and driver license to a customer. If required the system should transfer data from an ID Card to a driver’s license and information from a Driver’s license to an ID Card.


Driver’s License Records

DL 130

The system should be able to provide individual, bulk, or batch

MVR/DLR information to other appropriate and designated agencies using either ad hoc or predetermined criteria, and maintaining accounting data associated with MVR/DLR requests.

DL 131

DL 132

The system should be able to provide driver licensing transactions, licensing history (supporting documentation) and certification of authenticity services.

The system should be able to produce individual, bulk, or batch commercial MVR/DLR in multiple formats (e.g., e-mail, fax, hard copy format).

Duplicate Licenses

DL 133

The system should be able to track the history of the issuance of duplicate licenses. Specifically, the number of duplicates issued should be indicated on the driver’s license record.

DL 134







The system should track historical information related to the issuance of duplicate licenses including:



Activity date.

Location.

Activity Reason Code (license turned in, duplicate issued, license stolen/lost).

User that issued the duplicate.

Identity Verifications

DL 135

The system should be able to verify an identity using key data elements (e.g., Social Security Number, Passport Number, Alien

Identification Number, Out of State Driver’s License Number, etc.).

Interfaces


DL 136

DL 137

The system should be capable of generating files that can be sent to a CDLIS and PDPS to update pointer records and temporarily lawfully present.

The system should stop an authorized user from performing a credentialing transaction if a CDLIS or PDPS suspension is returned.

Medical Conditions

DL 138

The system should provide the ability to capture selected medical conditions/restrictions of an individual on his or her customer record and then indicate them on the driver’s license in accordance with the Colorado Revised Statutes.

DL 139

DL 140

The system should have a way of alerting the medical reviewer that a scanned document is available for review.

The system should have a way to review status of medical review (e.g., pending medical board review, disqualified, qualified).

Organ Donor

DL 141

The system should have the ability to capture organ donor information records and send them to the Donor Alliance.

DL 142

The system should provide the ability for DMV patrons to specify whether or not (Y/N) they wish to be an organ donor and store this information on the customer file. A “yes” response will be marked with a notation on the driver license or

ID card.

Selective Services

DL 143 The system should provide the ability for DMV patrons to register for Selective Service and transmit that information via the Selective Service interface.

Social Security


DL 144

DL 145

The system should provide the ability to validate a Social

Security Number and status with SSA via SSOLV during credential application processing.

The system should be able to validate “last four” numbers of a

Social Security.

Renew Credential

DL 146

The system should provide the ability to automatically generate machine readable (e.g., bar code, QR code, etc) invitations (mail or e-mail) to renew based on credential expiration period.

DL 147

The system should have the ability to print custom and compliance messages on the invitation to renew.

DL 148

DL 149

DL 150

The system should provide the ability to route Internet renewals for printing and mailing the credentials.

The system should provide the ability to renew credentials through various delivery channels.

The system should be able to determine and generate both

Internet and in-office renewal eligibility, in an automated fashion.

Knowledge Testing

DL 151

The system should interface with an external knowledge testing system and allow for testing results to be captured to satisfy driver license requirements during the application process.

DL 152

The system should interface with the new automated testing and scoring system for all electronic written tests.

DL 153

DL 154

The system should provide an authorized user the tools to perform statistical analysis on test data.

The system should require mandatory testing when a CDL is upgraded to an additional CDL Class or endorsement, including consideration of the time frame business rules.


DL 155

The system should be able to accept and record information from a driver skill tests.

Testing

DL 156

DL 157

DL 158

DL 159

DL 160

DL 161

DL 162

DL 163

DL 164

DL 165

The system should provide the ability for authorized users or customers to schedule vision, written, and skills test appointments in person or on-line that are conducted at DMV.

The system should provide the ability to electronically accept and record test results provided by a third-party vendor.

The system should provide the ability to register authorized third-party service providers and their testers.

The system should provide the ability to verify that submitted tests are from an authorized third-party service provider.

The system should provide the ability to interface with the vision and written test stations to record the results on the customer’s credential record.

The system should provide the customer or DMV agent with the ability to access their schedule online.

The system should provide the ability to capture a history of test results.

The system should support a table driven history of driver’s previous medical conditions that will alert the DMV agent to take additional screening actions.

The system should notify the agent when the configurable number of testing attempts (written or driving) has been exceeded.

The system should provide the ability to register and track control forms (e.g. third party testers, DMV agents, etc.)

Req. ID Collect Fees

Collect Fees

DL 166

The system should calculate the fees and taxes due, depending on the service or product transaction type, service delivered, and tax, etc.

DL 167

DL 168

DL 169

DL 170

DL 171

DL 172

The system should provide the ability to perform payment verification for debit, credit and cash cards.

The system should post financial entries for collected payments and allow for multiple tender types per payment transaction and multiple service transactions per payment transaction.

The system should produce a transaction and detailed payment receipt for all fees and taxes paid for services delivered, including Donor Alliance donations.

The system should provide or be capable of integrating with a point of sale cash management system.

The system should provide that transactions will include reference information identifying the necessary identification of documents used in the transaction (e.g., transaction number, receipt number, etc.).

The system should be able to print out a receipt for payment that is separate from the receipt that acts as the temporary credential.

Produce Credential Req. ID

Issue Credential

Req. ID Produce Credential

DL 173

DL 174

DL 175

DL 176

DL 177

DL 178

The system should support the issuance of both permanent and temporary credentials.

The system should have the ability to issue applicable classifications, endorsements, restrictions, and other identifiers on the credential (e.g., Military/Veteran, Organ Donor, etc.).

The system should provide the ability to update and maintain history of credential information and status (e.g., duplicate, modify name/address, photo update, upgrade/downgrade, surrender).

The system should calculate the inception and expiration dates based on business rules.

The system should provide or support an interface with the credential issuance system.

The system should provide the ability to record and display the credential delivery method.

Req. ID General

DL 179

The system should automatically notify the examiner when the process was not completed before the customer leaves the office

(e.g. the photo was not taken, photo taken on the wrong document, document was voided in DL application, but the photo was not voided at the capture station, etc.)

Req. ID General

DL 180

DL 181

The system should allow for multiple services such as

Reinstatement, Driver's License, Motor Vehicle Record, etc. during a single visit, instead of separate transactions and several receipts.

The system should allow for a search of records using a combination of information (e.g., first five letters of last name, first initial of first name, last four of SSN/ITIN or date of birth).

The system should allow for additional Verification(s) provided by AAMVA to include:

DL 182

DL 183

DL 184

DL 185

 EVVER- Electronic Verification of Vital Events

Records

 VLS- Verification of Lawful Status- this would replace the SAVE requirement.

 US Passport Verification Service

The system should provide Deceased Record hard stops when information is received from CDPH or SSA, or other official sources.

The system should allow for only manual intake of customers who cannot demonstrate lawful presence or who can demonstrate temporary lawful presence, for new or renewal of driver’s permits, licenses, and identification cards at specific offices.

The system should not allow for manual or electronic submission and/or intake of customers who cannot demonstrate lawful presence or who can demonstrate temporary lawful presence for Commercial driver credential.

Driver Services

Req. ID Receive Report or Conviction-Based Request

Process Driver Services Information/Requests

DS 1

The system should support the receiving of all types of electronic records and updates from in-state and out-of-state entities (such as but not limited to, courts, CBI/CCIC, CDLIS, and NDR/PDPS, CDHS, CDPHE, Colorado Interactive (and related systems), and allow for additions and deletions and modifications of such support).

DS 2

DS 3

DS 4

DS 5

The system should support the receiving and scanning of OCR and non-OCR forms and correspondence in conjunction with a

Document Authentication System (DAS). All documents are scanned, indexed, stored, and retrieved electronically by authorized users. For example, Colorado Certificates of Title are printed documents and therefore could be converted to text by OCR whereas a hand-written application cannot.

The system should provide the ability to process driver record action requests including, but not limited to: convictions, report-based offenses, expunge or rescind a court order, court affidavits, reinstatement requests, and results of a hearing or appeal, and include at least all current record processing actions and capabilities, allowing for expansion.

The system should support the auto-adjudication of record action requests (e.g., record/amend the conviction or request, violation/code, evaluating the request in the context of prior history and current status and taking the appropriate action

(suspending the license, restoring license, generate relevant correspondence)) with use of a business rules engine or similar technology. This should include all citations and convictions from other state, tribal, federal, and International jurisdictions.

The system should have the ability to record and associate record action requests with the customer record, for the purpose of auditing.


DS 6

DS 7

DS 8

DS 9

DS 10

DS 11

DS 12

DS 13

The system should provide the ability to send an alert to a driver services work queue for those requests that are not configured to auto-adjudicate or are too complex.

The system should provide the ability to record and track all types of administrative driver record actions and hearing requests, and record the results. The system should also be able to indicate when certain driving privileges are pending a decision by the hearing officer or by the court.

The system should have the ability to track all administrative actions, suspensions, and revocations pending and sustained, and provide authorized users with an alert of multiple actions and pertinent record information.

The system should provide the ability to configure rules relating to violation/transaction codes relationship for generating the sanction, reinstatement requirements, penalty, and reportability

(PDPS, CDLIS, MCSIA, etc.) for commercial and noncommercial driving privileges.

The system should comply with the requirements of all applicable federal requirements (e.g., CDL/MCSIA, FMCSA,

AAMVA, National Driver Registry), compacts (i.e., DLC/DLA,

NRVC), and state laws for sanctioning.

The system should have the ability to add, modify, remove, or expand elements in order to remain in compliance with federal requirements, compacts, and state laws as needed.

The system should support the ability to produce and process driving history views for both customer-facing and for department only use, based on agency rules.

The system should track all record search requests, and at a minimum, document the requestor, the date of request, the electronic signature of the requestor, the reason for the request, and the receipt of the request.


DS 14

DS 15

DS 16

DS 17

DS 18

DS 19

DS 20

DS 21

The system should be capable of producing driver history communications in plain English, (e.g., including interpretation of codes into meaningful statements that are easily understood by the driver, etc.) both internally and externally.

The system should electronically send all withdrawals created on out-of-state CDL holders that are highway safety related to the State of Record (SOR) through CDLIS.

The system should identify and accept electronically submitted files such as accidents, failure to appear, failure to pay, court information, and failure to comply actions, and apply necessary restraints.

The system should provide authorized users the capability to apply a configurable and/or timed “hold” on the driver record when pending an action or decision, such as a medical review / special exam.

The system should include processing for Hearings and Appeals for DUIs and other motor vehicle related offenses, medical decisions, and any administrative actions.

The system should be able to provide ad-hoc and userprogrammable fixed reports such as, but not limited to: disqualifications applied to record, penalties to be assessed, and

CDL Transactions.

The system should be configurable to use the most current approved set of transaction codes (e.g. Common codes,

AAMVA codes, municipal codes, etc.) for all accidents, convictions and withdrawals posted within the drivers system.

This includes both in-state and out-of-state records and should capture codes used at any point of time in history.

The system should provide an interface and tools to maintain transaction codes and accidents/convictions/withdrawals transmitted between jurisdictions.


DS 22

DS 23

DS 24

The system should allow the electronic update of a citation disposition to the driver record from the court.

The system should provide capability to easily configure datetimed business rules once to take effect on all subsequent actions.

The system should allow the intake, electronic or other, of arrest/conviction information and court disposition/deposition information, according to the business rules and statutes of the

State regarding driving privileges, to include the Colorado

Penalty Assessments process.


DS 25

DS 26

DS 27

DS 28

DS 29





































The system should provide the ability to maintain a table of violations including penalty values (such as points). This table will include, but not be limited to:

Violation.

Violation/Offense date.

Penalty nature/value.

Nature of Offense.

Demographic information from tickets (e.g., name, driver’s license number, date of birth, etc.).

C.R.S.

Speed Citation Details.

Additional CDL Violations.

Citation number.

Vehicle information (e.g., VIN, license plate, make, model).

Court case number.

Agency case number.

Conviction date.

Date of issue.

Accident.

Original charge.

Surcharge.

Proof of Insurance

The system should provide the ability to add, and modify withdrawal types as required.

The system should provide the ability to maintain a table of escalations for driving offense and corresponding restrictions.

The system should provide the ability to administer and/or process a court order for those received electronically and those data entered from hard copy.

The system should provide the ability to input information from a driving violation ticket to an individual’s driving record.


DS 30

DS 31

DS 32

DS 33

DS 34

DS 35

DS 36

DS 37

DS 38

The system should provide an alert and track the activity when a citation is entered and there is information requiring an express consent or revocation packet to follow.

The system should provide the ability to suspend an individual driver’s license privilege as the result of a conviction that results in a restraint (e.g., points suspension).

The system should have processes that automatically perform date/time triggered activities (e.g., suspension/reinstatement related tasks).

The system should be able to perform prior court processing on convictions and withdrawals including those received from a driver history record (another state) and determine the appropriate withdrawal.

The system should maintain user-maintained business rules that identify prior court processing actions based upon convictions or withdrawals.

The system should modify withdrawals based upon the conviction or previous withdrawal actions. If the “cause” of the withdrawal is modified the system should update the withdrawal to reflect the change and generated automated correspondence as appropriate.

The system should display, add and modify (both automatically and on demand), any restrictions, endorsements, time limits, and special license provisions.

The system should provide an alert when required data is not included in a record, such as a citation or express consent.

The system should be able to receive and post convictions electronically through CDLIS from other states. The nightly analysis program must treat these convictions as if they happened in Colorado and apply any federally mandated withdrawals.


DS 39

DS 40

DS 41

DS 42

DS 43

DS 44

DS 45

DS 46

DS 47

DS 48

The system should be able to receive the notice to negate a conviction received electronically from CDLIS and delete the conviction from the system and if necessary rescind a withdrawal. Deletion of conviction or rescinding a withdrawal should be reviewed and approved prior to the action being posted.

The system should be able to receive and post a withdrawal electronically through CDLIS from another state.

The system should be able to receive a notice to negate a withdrawal electronically though CDLIS and rescind any applicable withdrawals that previously posted to our system.

The system should be able to record TSA Hazmat background checks.

When Colorado has a pointer at CDLIS, the system should automatically surrender the license on our record when we receive notice that an individual has surrendered their Colorado license to another state. It must also update our record to show that we are no longer the state of record.

When another state has a pointer at CDLIS the system should automatically update our record to show that we are the current state of record after we have issued any type of license.

The system should have user friendly CDLIS reports including error messages and translation

The system should allow the business user to initiate the

AAMVA CD31 report upon demand.

The system should allow the business user to initiate the PDPS clean file upon demand.

The system should be able to take individual CDLIS and PDPS

UNI history messages (H2-H7) and format them into a readable and printable format for business users


DS 49

DS 50

DS 51

DS 52

The system should have a solution to send add, change and delete messages to PDPS (NDR).

The system should conform to the recommendations of the

NDR Working group which will be incorporated into final federal rulemaking from NHTSA.

The system should be able to receive and post all required history received electronically through CDLIS from a Change

State of Record.

The system, when required by the business user, should post

PDPS State to State history information when received electronically.

DS 53

DS 54

DS 55

DS 56

The system should reconcile a customer’s proof of insurance documentation submitted by the customer against the information provided by an insurance company, including outof-state driver insurance.

The system should provide the ability to input and lookup a suspension to identify any attorney listed in the record.

The system should act on driving privileges based upon vehicle registrations found to be uninsured based upon State-controlled business rules and the Financial Responsibility Act (FRA).

They system should maintain a table of business rules that maintain driving restrictions to Colorado drivers who are found to not have vehicle insurance (e.g., FRA)

DS 57

The system should be capable of supporting insurance cancellation activities.

Driver Records


DS 58

DS 59

DS 60

The system should be able to modify the driver record maintenance period (archive time) for accident, violation/conviction, and suspension/withdrawal information is maintained with a parameter table. Required maintenance period is determined by the CO DOR Document Retention policy except for Commercial vehicle data which should be maintained per Federal legislation.

The system should have the ability to have user defined record change types that may include a note when required.

The system should support and designate a driver cancelation by the authorized user that has the responsibility for determining sanctions and clearing actions.

DS 61

DS 63

The system should provide an authorized user the ability to produce a driver status (e.g., valid, suspended) for a customer or law enforcement.

Driver Record Update

DS 62

The system should provide the ability for authorized users to perform corrections on driver records that have been found to be incorrect.

The system should be automated to perform all Driver Services related business processes (suspension/reinstatement, driving record creation/update, interaction with stakeholders – driver/courts/etc.) automatically and timely with minimal user interaction.

DS 64

The system should be able to combine duplicate and skeleton records.

Search


DS 65

DS 66

DS 67

The system should provide an authorized user with customer search capabilities using, but not limited to, data collected, such as customer information (e.g., name, driver’s license number, address) or vehicle information (e.g., VIN, license plate number, title number) to identify an individual(s), vehicle(s) or an address(s).

The system should be able to track all inquiries (online or via interfaces) and releases of MVR/DLR data. Such tracking should include requestor’s name, exemption claimed, specific record released, inquiry date and time, specific node used to access data, and person or automated system performing the inquiry. Note: Some inquiries may not allow the customer information to be released, it is requested that the inquiry be recorded along with a status for the reason the request was not satisfied.

The system should have the ability to identify and flag data that can be printed and data that should be redacted.

Req. ID Process Citation/Record Services Action

Withdraw Driving Privilege

DS 68

The system should provide the ability to automatically generate a notice (of immediate or pending action) to the driver and appropriate external entities (PDPS, CDLIS, employers, etc.) for all pending actions to include CDL notification to other jurisdictions within 60 days, or as required.

Req. ID Process Citation/Record Services Action

DS 69

DS 70

DS 71

DS 72

DS 73

The system should use business rules established for violation/conviction/Transaction codes, driver history, current suspension, etc. and determine whether there should be a restriction, suspension, revocation, disqualification or cancellation applied to the driving privilege.

The system should provide the ability to configure and implement business rules to automatically evaluate the current action in the context of other driver record actions recorded on the driver record and notify or alert queued electronically or hard copy.

The system should support the continual monitoring of the driver record for compliance issues and take appropriate action for failure to comply.

The system should be able to identify drivers and apply restraint rules, and process the restraint automatically. Appropriate alerts should be sent to authorized users.

The system should provide a case and correspondence tracking system that generates letters from standardized templates, and integrates with a DAS.

Req. ID

Administrative Hearings

Conduct Hearing Support

Req. ID Conduct Hearing Support

DS 74

The system should be able to capture and store all hearing requests, hearing officer notes, and hearing results including related documents and associate it to a customer record. The system should also allow for manual edits to this data as appropriate.

Establish Re-instatement Criteria

DS 75

The system should provide the ability to automatically establish the driving privilege re-instatement criteria based on authorized user-defined rules relating to the suspension code and driver history.

DS 76

DS 77

The system should have the ability to track all administrative actions, suspensions, and revocations pending and sustained, and provide authorized users with an alert of multiple actions.

The system sets the suspension duration along with other criteria, e.g., notification of insurance, pay reinstatement fee, attend driver school, attend safety school, etc. in compliance with state and federal laws.

Req. ID Resolve Action/Reinstate License

Reinstate Driving Privilege

DS 78

The system should provide for the ability to expunge or modify records as required by court orders.

DS 79

The system should provide the ability to seal records.

Req. ID

DS 80

DS 81

DS 82

Resolve Action/Reinstate License

The system should provide the ability to rescind any withdrawal, action, conviction, etc., and track the rescind action.

The system should support the continual monitoring of the driver record, record re-instatement requirements completion and initiate a restoration work flow when all requirements are met.

The system should provide the ability to automatically generate a notice to the driver and other parties (PDPS, CDLIS, etc) of the restoration of their driving privileges.

Notification

DS 83

The system should automatically generate a new or revised suspension letter when changes are made to suspension dates.

DS 84

The system should validate that all applicable fees have been paid prior to reinstatement.

Req. ID General Driver Control Activities

General

DS 85

DS 86

The system should be able to provide/export and track bulk motor vehicle TLR/DLR data to approved external entities, allow for configurable and cancellation/renewal of service/data provision, and provide reporting on the same to authorized users.

The system should be able to interface with the Online Interlock

System (OIS).


DS 87

DS 88

DS 89

DS 90

DS 91

DS 92

DS 93

DS 94

DS 95

The system should be able to process all interlock related actions, track and process interlock financial aid, track testing and failures of interlock devices, vendor information, and all other currently supported interlock related features.

The system should process fatal motor vehicle accidents to trigger a manual record review for special exam by the Help

Desk or other designated party.

The system should interface with all Law Enforcement systems

(CCIC/NCIC/NLETS, messaging switch,) Etc.

The system should have menus in language and terminology conforming to those currently used by Colorado Motor Vehicle personnel.

The system should be able to provide extensions processing for license records, status, actions, withdrawals, etc., where appropriate.

The system should support both online and cashier payments for all applicable payment driven processes. (e.g. reinstatements, driver record searches, penalty assessments)

The system should provide user access tracking and reporting to authorized users for approvals, denials, permission levels, date of access, limitations on duration, for both internal and external users and agencies.

The system should be able to recreate a letter based on historical template and retain/export a digital image of any/each letter of correspondence generated and sent to any other state or individual on demand.

The system should be able to automatically track letters generated and distributed (mailing verification) and incorporate whether the document was mailed or not in the record.


DS 96

DS 97

DS 98

DS 99

DS 100

DS 101

DS 102

DS 103

The system should have the ability to process returned mail using bar codes and digital imaging for analysis and indicate returned mail in correspondence tracking in the record.

The system should be able to accept and process electronic accident reports, allow for manual data entry and modification of accident reports, counter reports, partial reports, etc., and identify the source of the report.

The system should be able to process both FRA and PAX

(penalty assessments) accounting and cash flow tracking.

The system should be able to capture payment processing information and interact with department accounting and related software and assignment of fees/surcharges.

The system should be able to compile ad-hoc reports based upon all data collected for authorized individuals to include the ability to search by one or multiple wildcards.

The system should be able to collect pertinent files and generate certified and non-certified reports for courts, attorneys, express consent, motor vehicle record searches, ad-hoc reporting, and fixed reported and be able to fax or email and track (with default to encrypted email) directly from the system.

The system should be able to verify address validity via the

USPS or other like address recognition source before accepting the address into the system - and have the ability to override with approval when necessary.

The system should be able to process short checks/NSF for both in-state and out-of-state transactions, take appropriate action on the record, and automatically generate appropriate correspondence.


DS 104

DS 105

DS 106

DS 107

DS 108

DS 109

DS 110

The system should provide customer service scripting (such as may be found in drop-down menus to explain the current state of any record) in plain English to assist customer service representatives.

The system should be able to electronically track and queue workflow of DMV case numbers and respondents and their appeals through the appeal process from the initial hearing through the appellate courts and provide reporting on the same to include stays, DA/AG representation, dispositions, final orders, mandates, and the like.

The system should provide configurable and comprehensive stats collection and reporting and be able to export the same in several formats to include CSV, Excel, PDF, etc.

The system should be able to process and track electronic documents for viewing during manual data entry (paperless document processing) and be able to report where any electronic document is in the workflow process through to completion and export to permanent electronic storage for later retrieval if needed.

The system should be able to send tasks and associated documents to other assigned users to complete one or more business transactions (e.g. a ticketing style system where a task can be escalated to a supervisor or other business unit and tracked.)

The system should provide ability for electronic approvals by an identified authority before work continues through electronic workflow process.

The system should be able to process electronic requests for forms, track form inventory, queue form ordering, and e-mail electronic versions of authorized forms directly from the system to external customers.


DS 111

DS 112

DS 113

DS 114

The system should allow for customers, with appropriate access, self-service for driver information (e.g. penalty assessments, reinstatements, crash reports, etc.).

The system should provide the ability for authorized users to manually correct Conversion records (e.g., Legacy DLS data conversion errors to DRIVES or electronically submitted records, etc.)

The system should process and track law enforcement proofs of service issued to respondents.

The system should be able to query records utilizing a

'SOUNDEX' functionality in order to search for and locate records with similar names, variations of hyphenated names, dates of birth, etc.

Req. ID Investigations

General

INV 1

INV 2

INV 3

The system should initiate appropriate background, criminal and security checks depending on the type of customer (e.g., non-

U.S. citizen) and the type of credential/endorsement they seek to obtain (e.g., CDL).

The system should be able to identify and alert when patterns exist (e.g., same individuals using the same address).

The system should be able to identify and link skeleton records that belong to the same individual.


INV 4

INV 5

INV 6

INV 7

INV 8

INV 9

INV 10

INV 11

INV 12

INV 13

The system should be able to perform a periodic “cleanse” to identify records based on data inconsistencies (e.g. multiple records that appear separate because the first and last names are swapped in one of the records).

The system should generate an alert when the same unique identifying number (e.g., SSN or ITIN) are used on multiple records.

The system should be able to detect and provide an alert when an out-of-state DL or ID number is provided which does not conform to the numbering conventions of that state.

The system should allow Motor Vehicle Investigations to place a visible alert message in the customer record to indicate potential fraud investigation.

The system should allow for a separate, secure credential licensing system for authorized law enforcement covert operations.

The system should allow for the option to have an address or address history or name history remain confidential/hidden from anyone accessing the system.

The system should allow for the option for a law enforcement designation to be selected indicating that the card holder is a law enforcement official.

The system should allow for a document to be produced via virtual image as part of the covert credentialing system.

The system should allow for the covert system issuer initials to be changed at any time to avoid detection that covert documents are being issued by the same person and same location.

The system should allow for images produced in the covert system to remain separate from files accessed by authorized users.


INV 14

INV 15

INV 16

INV 17

The system should allow for an investigator to view the documents used to obtain the DL/ID/Permit.

The system should have the capability for investigations to add notes that have an option to be visible to all users or only authorized users.

The system should be capable of locating records with discrepancies that include the same citation or other document on multiple records or the citation and department action on separate records.

The system should be capable of capturing patterns and trends within Title/DMV systems such as the same POA, Notary and applicant name on multiple applications.

Exceptions Process

INV 18

The system should have the ability to generate reports specific to:

















The number of individuals issued or denied a document on the first visit.

The number of individuals advised to produce more documentation.

The length of time between an unsuccessful first visit and ultimate approval.

The number of individuals who fail to return, by office,

The number of individuals that requested Exceptions

Processing each month

The outcomes of the Exception Process by office each month,

A summary of the main reason for denial under Exceptions

Processing and

The number of hearings requested.


INV 19

The system should allow for a notice to be automatically generated for an incomplete application or denied application, with the ability to modify the language of the notice as necessary.

Titles and Registration

Req. ID Collect & Verify Title and Registration Documents

General

TR 1

TR 2

TR 3

The system should provide the ability for authorized lien holders to do electronic lien extensions, transmit lien releases, and view lien with regard to the following types of liens:





Financial Institutions.

Tax Liens.

The system should use SVID standard documents and processes and validate SVID when possible.

The system should recognize other state DL/ID number formats and alert if the provided number does not conform to the standard.

Customer Access

TR 4

The system should allow the seller with proper credentials to initiate a secure Internet transaction to transfer the title to a buyer, according to established CO policies and rules for title transfers.


TR 5

TR 6

TR 7

TR 8

TR 9

TR 10

The system’s title transfer policies and rules should be written in plain language and be easily accessible any time throughout the transaction. System should inform users if and why they are non-compliant.

The system should allow the buyer with proper credentials to access a title transfer in process on the Internet and validate the information, according to established CO policies and rules for title transfers.

The system should allow the seller to access a title transfer in process on the Internet and validate the modified information to allow processing of the transaction, according to established CO policies and rules for title transfers, and the buyer wishes to change information entered by the seller.

The system should enable an electronic interface for online,

Web-based access to record and history and collect any fees applicable to accessing the information.

The system should provide customers with online access to information regarding their vehicle’s title and registration status including, but not limited to, emissions and insurance requirements.

The system should allow customers to log in and pay for and renew their registrations, provide proof of insurance, and proof of emissions testing, according to established CO policies, rules and statutes.

Title Application Processing

TR 11

The system should allow the seller and/or licensed dealer to enter all vehicle and sale information required for the transfer of a title from one CO customer to another.

TR 12

The system should provide confirmation of title transfer transactions.


TR 13

TR 14

TR 15

TR 16

TR 17

TR 18

TR 19

TR 20

TR 21

TR 22

The system should be able to capture title application information when a title application is entered by a user, including user ID and transaction (e.g., date and time) information.

The system should issue a unique title number for the application when the application is processed.

The system should provide the ability to process applications for title services (e.g., new, voluntary, and involuntary transfers; cancellations) and includes requirements common to title and registration.

The system should provide the ability to issue, store, print, and maintain motor vehicle titles electronically.

The system should allow the registered or legal owner(s) of a vehicle the option of titling without applying for registration, according to established CO policies, rules and business processes.

The system should have a mailing indicator that points to which owner address (es) to which the title and renewal notifications are to be mailed.

The system should be able to process transactions for titles that are not stored electronically, e.g., paper or purged titles.

The system should allow a title, registration, or NMVTIS record to have an area for comments to be stored.

The system should be able to print and track the issuance of duplicate titles and reprint titles over the life of the vehicle.

Tracking should include identifying the user who issued the duplicate, reason, and a date stamp.

The system should capture all title transactions types, the ID of the person performing the transaction, the location, etc. (e.g., who and where a title was printed).


TR 23

TR 24

TR 25

TR 26

TR 27

TR 28

TR 29

TR 30

TR 31

TR 32

TR 33

The system should provide the capability for wildcard and

Boolean searches for title, based on key attributes, including but not limited to: current and previous owners, customer number, partial customer name, title number, plate number, full or partial

VIN, lessee, lessor, lien holder, permit number, etc.

The system should have the ability to generate a ‘Certificate of

Search’ showing the title history or record search as may be required.

The system should capture the Out-of-State Title Number and

State abbreviation.

The system should be able to accept and change the jurisdiction code information received when an address is entered.

The system should provide the ability to check the status of the title when processing a title, vehicle or registration transaction and suspend the transaction based on business rules. Anytime the system makes a decision, there should be an option (hot-key or info button) to see what business rules triggered the decision.

The system should allow an unlimited number of owners on a title.

The system should provide the ability to capture seller information (dealer/ private seller) as well as date of purchase, purchase price, trade-in amount, etc.

The system should be able to differentiate vehicles by sales tax exempt status and use that information when calculating taxes and fees.

The system should be able to determine sales tax based on state and local requirements and rules for valuation.

The system should process batch title applications.

The system should alert an authorized user when there is a duplicate title.


Validate Customer/Documentation

TR 34

The system should provide for the double verification of VIN and Odometer.

TR 35

The system should be capable of creating a flag odometer if the mileage looks excessive or the Odometer code has changed.

TR 36

TR 37

TR 41

TR 42

TR 43

The system should support a title and Registration Fraud

Detection system or techniques.

The system should be able to provide customer compliance checks for title transactions as defined by Colorado titling business rules.

Validate Vehicle Compliance

TR 38

The system should be able to check vehicle compliance rules as they relate to the title process and provide information to user explaining why a vehicle is non-compliant.

Record Vehicle Brands

TR 39

The system should have the capability to flag a previous brand

(e.g., junk, salvage rebuilt).

TR 40

The system should have the capability to flag a non-repairable title (e.g., For Parts Only) and interface with NMVTIS alerting operator when cancelled, notify owner of record if valid registration that plates are cancelled.

The system should maintain brand history associated with the title including brand and state.

The system should provide for the removal of brands recorded in error by an authorized user with the proper system security role and interface with NMVTIS and VHDB.

The system should use AAMVA standard brand designations and allow for entry of CO specific brands if needed.


TR 44

TR 45

The system should be able to have vehicle brands easily added as determined from time-to-time by statute.

The system should be able to prioritize title brands and record the title brand based on priorities established by business rules

(e.g., Flood brand has priority over all other brands and may not be overwritten or pushed to history by any other brand).

Lien Records (Financial Institution)

TR 46

The system should be able to select lien holder information from a list of common lien holders, driven by a valid lien holder code table, when entering a lien holder onto a vehicle record.

TR 47

TR 48

The system should provide the ability to maintain a list of common lien holders, driven by a valid lien holder table, to be selected from when recording a lien.

The system should support the administrative maintenance of lien holder tables and mechanisms by authorized users.

TR 49

The system should be able to record a new lien on a vehicle title record and issue a lien reception number.

TR 50

TR 51

The system should record a lien release for a vehicle using the unique lien identifier.

The system should be able to accept and record information for multiple lien holders and calculate the lien maturity date.

TR 52

TR 53

The system should provide inquiry capability for lien holder information associated with customers by Lien holder Name,

Lien holder ID, and Lien holder.

The system should allow a secondary and subsequent lienholders to be promoted when the primary lien is removed or released.

Transfer Title


TR 54

TR 55

The system should be able to notify the owner and any lien holders, when a request for lien sale is received from vehicle repossession action.

The system should maintain a list of transfer reasons (voluntary and involuntary) and allow the title agent to select a transfer reason.

Title Application Notifications

TR 56

The system should notify an authorized user if a vehicle has a special handling status (canceled, junked, declared salvage, holds, short check, or abandoned) on a vehicle record.

TR 57

The system should provide an authorized user with warning to check for certain lien holder’s ID number when key part(s) in lien holder’s name or address as determined by the department detected.

TR 58

TR 59

TR 60

TR 61

The system should be able to automatically communicate, on a statewide basis, alert information online/real time (e.g., missing data fields, stolen titles from other states, and communications outage) to title examiners about titles transactions that have been initiated from any entity processing titles.

The system should notify the authorized user of the inability to issue a title based on issues with the customer or vehicle record.

The system should provide for programmable alerts based upon any changes in values that may initiate an alert.

The system should warn and instruct an authorized user that additional title documentation will be required to complete the transaction.

Registration Application Processing

TR 62

The system should minimize the amount of information to be captured at registration time (commercial, noncommercial), credential, or permit.


TR 63

TR 64

TR 65

TR 66

TR 67

TR 68

TR 69

TR 70

TR 71

The system should enable an authorized user to review and either accept or reject a personalized, special or sample plate request based upon security role.

The system should process batch registration applications, including the recognition and reconciliation of duplicate batches for duplicate individual registrations.

The system should be able to update any changes to registrant address information if required and record the transactions date, time, and the authorized user, when issuing a replacement registration.

The system should be able to interface to a recognized and proven address verification system, including State’s own address locator, with the ability to identify certain characteristics related to the address (e.g. business, mail drop, mixed use, emissions, etc.).

The system should provide the ability to identify the buyer and/or owner of a vehicle by Customer ID and/or Driver

License ID.

The system should be able to capture whether VIN has been verified, date, inspector, agency and location.

The system should be able to validate or invalidate a VIN supplied by a vendor and should highlight an invalid VIN to the authorized user during the application entry or review process.

The system should be able to set and update registration class/subclass based on information provided about the vehicle usage and body type.

The system should support error detection functionality including, but not limited to, the vehicle class being coordinated to body type, and the vehicle fuel type as identified in the VIN.


TR 72

TR 73

The system should support the automatic determination of fees based upon vehicle descriptors, license plate number, and/or address.

The system should provide the ability to process applications for registration services (e.g., new, temporary, vehicle transfers, renewals, plate transfers, class transfers, supplements, group transfers, plate replacement, tab replacement, decal replacement) and includes requirements common to title and registration.

Validate Customer/Documentation

TR 74

The system should be able to check customer compliance rules as they relate to the registration process (i.e., USDOT, MCS150,

IRP Plan, C.R.S., emissions, HVUT, PRISM Out of Service, prior balance due, Title data mismatch, etc.).

TR 75

The system should provide the ability to designate and validate an address where the vehicle is domiciled for tax and fee purposes.

TR 76

TR 77

TR 78

TR 79

The system should be able to designate addresses for specific purposes, including but not limited to: renewal mail billing, plate delivery, or emissions testing requirements.

The system should be able to determine the mailing address for the registered owner (e.g., lessee) when the vehicle is under lease.

The system should provide cross matching sub-systems or functionality that identifies inconsistencies and possible fraud

(e.g., VINs with multiple changes, old registrations, titles, moving vehicle registrations between multiple accounts with no title or changes).

The system should allow the housed or registration address for the vehicle to be updated by an authorized user with the proper system security role.


TR 80

TR 81

The system should validate insurance compliance by VIN and vehicle owner name and address, for the processing of MIIDB applications.

The system should be able to track the transaction completed by an individual using Power of Attorney.

Validate Vehicle Compliance

TR 82

The system should recognize and validate the VIN check digit extracting appropriate vehicle information for populating the record.

TR 83

TR 84

TR 85

TR 86

TR 87

The system should check the VIN to determine fuel type and flag those types that are capable of being plug-in electric vehicles.

The system should interface with the Emissions contractor and through a Web-based service to retrieve emissions test data and calculate next inspection date based on Colorado registration business rules.

The system should allow for the configuration of compliance rules (table driven) by DMV.

The system should allow for VIN explosion or decode and auto propagation of information based on the explosion.

The system should support and identify VIN discrepancies, and allow for corrections by authorized users.

TR 88

TR 89

The system should be able to check vehicle compliance rules as they relate to the registration/renewal process.

The system should be capable of checking insurance status through MIIDB, in real time.

Renew Vehicle Registration

TR 90

The system should provide the ability to automatically generate coded (e.g., bar, QR, etc.) renewal notices based on registration expiration period.


TR 91

TR 92

The system should provide for the ability to generate renewal notices via a customer selected method (i.e., e-mail, Twitter, text message, mail etc.).

The system should have the ability to print custom and compliance messages on the renewal notice, including reporting period and USDOT status for IRP.

TR 93

TR 94

The system should support the registration and renewal of other vehicle types, via the Web site interfacing with NMVTIS,

MIIDB and Emissions.

The system should provide the ability to route Internet renewals to a State-defined location(s) for printing and mailing the renewed credential documents and registration receipt.

Renewals must be reviewed and approved by DMV staff before credential documents are mailed.

Transfer Vehicle (Plate)

TR 95

The system should provide the ability to transfer an existing plate and remaining equity to another vehicle.

TR 96

The system should apply business rules for permitting the transferring of a plate to another vehicle (i.e., same owner on both vehicles).

Replace Registration/Plates/Decals

TR 97

The system should support replacement of all or specific plate types, tabs, and decals based on user-defined selection criteria, including other vehicle types as appropriate.

TR 98

The system should track number of tabs or plates reissued providing reporting based on established business rules.

Req. ID Process Information and Collect Fees

General

TR 99

TR 100

TR 101

TR 102

The system should provide the ability to require VIN validation for all transactions and should notify the operator in instances where these are required.

The system should provide the ability to perform compliance checks based on vehicle identifiers (e.g., if the vehicle tax is current, there are no outstanding violations, emissions checks are current, insurance is in effect, safety violation, vehicle is not stolen, or on hold for other reasons and the registration is not suspended for some reason).

The system should allow an authorized user to add, de-activate and modify title transaction types by an authorized user with the proper system security role.

The system should allow an authorized user with appropriate access to search and edit a vehicle transaction business rules table (transfer title, new title, and other title) information by an authorized user with the proper system security role.

Electronic Titles

TR 103

The system should be able to send and receive messages of errors in title information to providers, a separate error comments field, and place inbound error message into a work queue for review.

TR 104

TR 105

TR 106

The system should be able to change the status of single or multiple titles from paper to electronic upon receipt of an electronic notification from the lien holder, and should send a confirmation to the service provider upon conversion.

The system should be able to process all electronic notices received formatted according to CO specifications.

The system should automatically and securely transmit electronic titles information.

Interface Functionality


TR 107

The system should provide the ability to interface, in real time, with entities identified in Table 3 – Current DLS and CSTARS interfaces.

Title and Registration Common Requirements

TR 108

The system should provide the ability to identify and retrieve registration and title owner of a vehicle by identifiers such as, but not limited to: customer ID, passport ID, driver license ID,

CO ID Card, CO/U.S. DOT number, name, plate number, permit number, account number, FEIN/SSN/ITIN, title number, etc.

TR 109

TR 110

The system should support a titled owner to be different from the registration owner.

The system should have the ability for an authorized user to conduct wildcard and/or Boolean searches for a vehicle or person by key attributes including but not limited to: customer name or number, phone number, address, e-mail address, fleet number, VIN, title number, partial name, plate or partial plate number, DL number, etc.

TR 111

TR 112

The system should provide the ability to require user-defined mandatory information by vehicle type in order to create or update a vehicle record.

The system should provide the ability to issue and track replacement Vehicle Identification Numbers and trailer IDs.

TR 113

TR 114

TR 115

The system should provide the ability to accept variable length alphanumeric VIN numbers.

The system should provide the ability to capture/display multiple VIN and designate as primary or secondary.

The system should support the loading of the proper fuel type based on VIN and flag those that are capable of being plug-in electric vehicles.


TR 116

TR 117

TR 118

TR 119

TR 120

TR 121

TR 122

TR 123

TR 124

TR 125

TR 126

TR 127

The system should track all fuel types as well as vehicles with multiple fuel types (hybrid vehicles).

The system should provide the ability to retrieve and identify vehicle valuation data from an external source or to be entered.

The system should provide for the ability to set and verify exemptions at the vehicle level.

The system should provide the ability to associate or remove a vehicle from a Fleet.

The system should provide the ability to enter detailed notes about a vehicle.

The system should provide the means to document why corrections were made to a record, including but not limited to audit fields with time date stamp, user information.

The system should be able to record the receipt and details of a

Release of Financial Liability associated with a vehicle.

The system should provide the ability to track the gross vehicle weight, gross vehicle weight rating and the vehicle empty weight.

The system should provide the ability to create a title history for vehicles that are classified as ‘suppressed’ (e.g., the vehicle is owned by someone whose identity is suppressed).

The system should support the use of state and federal sources to standardize and validate vehicle information (e.g., NMVTIS,

DOT, CO DOR, and NCIC).

The System should allow an authorized user to update pending title or registration transactions.

The system should support the mass renewal of Fleet Vehicles at a configurable time every year.


TR 128

TR 135

The system should support the mass renewal of Dealer,

Manufacturer, Fleet, Transporter, and Depot plates at a configurable time every year.

TR 129

TR 130

The system should support the mass renewal of Undercover license plates at a configurable time every year.

The system should be able to place transactions on “hold” for processing at a later time (e.g., when a registration request is approved but payment has not been received, stolen vehicle, or bad check). The hold time frame should be business rule driven.

Title Processing

TR 131

The system should associate vehicle ownership to a customer record. The type of vehicle ownership including the multiple owners should be accommodated.

TR 132

TR 133

TR 134

The system should identify title status (e.g., new) on vehicle record.

The system should allow for scanning of title paperwork to be used in lieu of hard paperwork copies.

The system should associate and display scanned paperwork when a transaction is being performed on a vehicle.

The system should capture and record on the vehicle record the origin of the title application (e.g., CO dealer, financial institution, or county office).

TR 136

TR 137

TR 138

The system should be able to accept corrections to prior title information when creating the application.

The system should enable an authorized user to find, review, and update the vehicle record.

The system should facilitate an authorized user with changing of the customer name information when printing new title documents.


TR 139

TR 140

TR 141

TR 142

TR 143

TR 144

TR 145

TR 146

TR 147

The system should capture all information from the title application plus the previous title and previous title transaction.

The system should require an authorized user to capture additional or less information based on the title status (e.g., new, a canceled, junked, declared salvage, or abandoned).

The system should check law enforcement data bases to ensure the vehicle has not been stolen or is being held by law enforcement for other reasons.

The system should issue a unique title number on each application.

The system should post the title transaction as “needs work” or immediately issue the title depending on the title type when the application has been completed at the county office.

The system should be able to place a title application in a rejected status based on business rules.

The system should capture on the title transaction the nature of the transaction, indicating whether the transaction was standard, or involved a specific transfer by operation of law (e.g., bankruptcy, lien sale, seizure), had foreign documentation (e.g., vehicle last titled/registered in another country, in the military, by the federal government), required a title brand (e.g., bonded title, reconstructed vehicle), or involved a special manufactured home transaction (e.g., statement of intent to declare manufactured home real property, reversal of declaration of manufactured home as real property, MAU – Certificate of

Ownership).

The system should allow for the rejection of a title application based on table driven reasons and communicate back the specific reason for rejections.

The system should capture with each title transaction a title transaction type.


TR 148

TR 149

The system should allow the option of issuing a paper title or maintaining an electronic title, when a vehicle owner is applying for a title with no lien.

The system should be able to capture and maintain all information from a salvage title associated with a vehicle record.

TR 150

TR 151

The system should be able to allow creation of a salvage transaction against a vehicle record that includes a complete vehicle description, name and address of owner, issue date and time, any title brands, authorized user comments, user ID, and indication of which salvage program applies, and that salvage declaration was due to age or value.

The system should auto populate the owner name and address when a dealer title transaction is completed by pulling in the information from a dealer type database by dealer number.

Title Work Flow

TR 152

The system should prioritize and expedite title work using a work flow process.

TR 153

TR 154

TR 155

The system should be able to track and identify status of applications being processed. (e.g., pending, rejected, held, suspended).

The system should allow authorized users to modify title transaction information even if they did not initiate the title transaction.

The system should allow for a documented override and approval process.

TR 156

The system should allow remote offices to scan and upload title paperwork for processing, rather than assembling and mailing the paperwork to the central office.

Maintain Title Information/Status


TR 157

TR 158

TR 159

TR 160

TR 161

TR 162

TR 163

TR 164

TR 165

TR 166

The system should provide inquiry capability for records that have holds placed on them.

The system should be able to receive a transmittal report from each jurisdiction and assign the transmittal report to an examiners work queue or an overflow queue based on the jurisdiction, and change the status to “in process” for each application in the transmittal.

The system should be able to restrict title transactions from occurring when a vehicle title has a status that prevents a service from continuing (e.g., junk status, holds, etc.).

The system should be able to link title holds to registration holds, preventing registration transactions for the vehicle and generate a letter to owner of record of cancellation of plates for those actively registered.

The system should be able to retrieve the pending transaction, when a change is requested to a title or registration application that has been submitted.

The system should be able to produce, send, and track paper or e-titles.

The system should be able to update the title status to cancel when a vehicle is titled in a new state (another jurisdiction). In addition, the system should log the new state where the vehicle has been titled.

The system should provide the ability to inquire on title and title application status.

The system should stop a duplicate transaction from being completed when a newer record exists.

The system should track each time a duplicate title is issued

(such as duplicate number one, duplicate number two, and so on).


TR 167

TR 168

The system should have the ability to issue a ‘corrected’ title

(e.g., correct lien information, correct erroneous title information).

The system should maintain a “Title Status” (e.g., Active,

Assigned, Canceled, Duplicate, Surrendered, Stop Bond,

Withdrawn, Revoked, purged ad valorem, tax sale etc.).

Lien Processing

TR 169

The system should be able to release the lien, record the date the lien was satisfied, change the mail-to address for the title and print or provide an electronic title, when electronic notification is received that a lien on a title has been satisfied.

TR 170

TR 171

The system should be able to record a new lien in a vehicle record.

The system should be able to remove a lien from the vehicle record when a request is received to remove a lien.

TR 172

TR 173

TR 174

The system should be able to match Lien Holder information against known lien holders when entering a lien holder onto a vehicle record.

The system should be able to record and process a request for a lien holder title when it is received for a vehicle that is titled out of state.

The system should provide processes to support miscellaneous lien types other than those for financial Institutions and to validate compliance per a configurable checklist driven by related statutes.

TR 175

The system should be able to record the lien status change on the vehicle record, when a lien holder notifies the DMV that a lien has been satisfied.

Registration Processing


TR 176

TR 177

TR 178

TR 179

TR 180

TR 181

TR 182

TR 183

TR 184

TR 185

TR 186

The system should provide the ability to set registration and plate expiration periods by class/sub-class or by fleet.

The system should provide the ability to identify that the registration is temporary or permanent.

The system should provide the ability to track the status of temporary and permanent Registrations.

The system should link temporary registrations with permanent registrations and auto populate permanent registration screens with vehicle and owner information from the temporary registration.

The system should provide the ability to register a vehicle without titling in the state of CO pursuant to business rules.

The system should provide the ability to print a decal or sticker at time of sale through a Point of Sale system.

The system should support the issuance of month and year stickers for motor vehicles. Sticker number should be unique and related to plate number.

The system should print registration receipt (card) and allow for and track a reprint on request for registration receipt as well as reprint a sticker.

The system should complete the registration and electronically order the vanity or special interest plate from the State designated production facility and validate if the State rules and statutory processes for configurations, offensiveness, duplications or other reasons apply.

The system should maintain plate history and status (on hand, lost, destroyed, issued etc.).

The system should be able to determine if a plate number that has already been issued in any county or by the State is active and prevent a duplication of plate numbers.


TR 187

TR 188

TR 189

TR 190

TR 191

TR 192

TR 193

TR 194

TR 195

TR 196

TR 197

The system should be able to maintain an electronic archive of the current and previous owners/registrants of a given vehicle.

The system should enable the authorized user to make the required changes to the registration record.

The system should calculate emissions requirements based on business rules (e.g., model year, plate type, fuel type, and registration address).

The system should ensure the vehicle record is in a valid status so that a registration record can be created or updated.

The system should be able to convert and support registration holds utilized by CO DMV.

The system should be able to process registrations associated with special eligibility programs (e.g., veteran, persons with disability, placards and plates).).

The system should track ALL plate/registration transactions from request through issuance/completion.

The system should complete the registration and electronically order the plate from the plate manufacturer, when a requested personalized plate or print on demand plate is approved and payment received.

The system should update a vehicle record upon receipt of the print on demand plate activation file from Correctional

Industries.

The system should be able to support registration cancellations and reinstatement.

The system should enable the authorized user to make the required changes to the registration record, maintain a historical record of the changes to include who performed the transaction, when the transaction was performed and where the transaction occurred.


TR 198

TR 199

TR 200

TR 201

TR 202

TR 203

TR 204

The system should be able to recognize whether a vehicle requires registration and which type it is eligible for, and if it is currently titled, when a new registration transaction is initiated.

The system should be able to create a new registration using the information from the vehicle’s title record, when an eligible registration is transferred to another vehicle.

The system should allow an authorized user with appropriate access to place a “Hold” on a transaction associated with a customer or vehicle that will prevent the transaction from being completed (without expiration date/time). The notice will be table based or free form text and will require a point of contact.

The system should be able to process vehicle registration from a table driven list of CO approved vehicle types.

The system should have the ability to track issued dealer plates through the title and registration system, track the number of plates the dealer qualifies for, and track by name and plate number.

The system should be able to require, validate, and track driver’s proof of insurance.

The system should provide the ability to retrieve requested temporary permit information using search criteria such as owner names, lessee names, VIN, permit number, and bar code.

Registration Renewal Processing

TR 205

The system should be able to add messages that are specific or unique to the registrant’s address and or county office and registration/vehicle type, when creating the renewal notifications.

TR 206

The system should allow department personnel to verify and validate specific renewal data prior to printing of group or individual renewal cards.


TR 207

TR 208

TR 209

TR 210

TR 211

TR 212

TR 213

TR 214

TR 215

TR 216

TR 217

The system should only send renewal cards to registrants eligible for renewal per eligibility qualification rules.

The system should be able to send registration renewal notification electronically and/or by other methods.

The system should allow for reprinting of the renewal card on request or the display of the same information, when a registrant loses their registration renewal card.

The system should calculate the renewal fees for the vehicle and type of registration when preparing the renewal cards/notice.

The system should use system configuration tables to determine the records to be grouped and sent to a ZIP/location code, county office or cards that will be printed and mailed to a registrant’s home address, when preparing the registration renewal cards/notice.

The system should be able to include all of the required information, when printing the renewal notifications.

The system should be able to identify the information to print on the title or registration, when an application is changed to current status.

The system should be able to create a new registration and decal, when registration is transferred to another vehicle.

The system should be able to determine which registrations require notification of renewal, based on the date, the registration type, and the amount of time remaining before the registration expires.

The system should accommodate business rules for emissions extensions to allow vehicle owners who are temporarily out of state to renew their registration.

The system should be able to issue replacement vehicle decals, when an applicant has lost or damaged the decals.


Registration Renewal Publication

TR 218

The system should be able to estimate how many renewal cards/notices will be printed/provided for a calendar year.

TR 219

The system should provide the ability to generate plate and decal reports. These reports will include, but not be limited to: plates/decals issued by branch by month, plates issued by plate type across one or more branches.

TR 220

TR 221

The system should produce a report of renewal notices to be printed/provided based on parameters set by an authorized user.

The systems should identify owners that have moved and provide advance notice of renewal to allow the owner sufficient time to make necessary address changes before the renewal notice is provided/sent.

Plate Processing

TR 222

The system should be able to print/display a list of plate requests based upon different criteria such as date range and where the request was initiated – county and state offices.

TR 223

The system should be able to assign a plate number and plates to a registration according to department rules, plate program and registration/vehicle type.

TR 224

TR 225

TR 226

TR 227

The system should be able to assign a reserved plate to the registration.

The system should be able to display the reserved plate number, when the renewal notice of a registrant who has reserved a plate is sent out.

The system should allow for comment information in a freeform area for registration plate.

The system should provide the ability to reuse license plate numbers and maintain license plate/registration history records.


TR 228

TR 229

TR 230

TR 231

TR 232

TR 233

TR 234

TR 235

TR 236

The system should be able to compare the requested personalized plate against a list of pending and previously issued, assigned, or reserved plates.

The system should be able to compare the requested personalized plate against a list of unacceptable words. Listing may be referred to as the “Invalid Plate Listing” table.

The system should allow an authorized user to delete a personalized plate request that has been approved but payment has not been received.

The system should allow an operator to access services that translate slang or other terms (e.g., UrbanDictionary.com and

Google Translate) to verify/validate word/configurations requested on personalized plates to ensure they are not offensive or misleading.

The system should allow for the automatic deletion of personalized plate request that have been on hold for business rule defined period of time.

The system should be able to place the personalized plate message into the list of pending plates when a request is approved.

The system should be able to issue replacement plates by placing an order for the manufacture of the same plate number, when an applicant has lost or damaged plates upon receipt of payment of fees.

The system will provide an edit to ensure the plate format is still valid when a replace plate transaction is processed.

The system should be able to include the specific plate reservation fee to the renewal data that is printed on the renewal forms.


TR 237

The system should maintain a replace plate application/transaction and identify if the application was satisfied.

TR 238

TR 239

TR 240

TR 241

The system should perform a check to compare the requested plate to a list of plate configurations that are maintained in a table.

The system should be able to both record the transaction and add the plate configurations to the plate order, when an application for sample plates has been approved.

The system should prevent the issuance of active duplicate plate numbers to include personalized plates unless authorized by users with specific levels allowing it or as defined in business rules.

The system should be able to accept and process, personalized plate application/requests via a Web-based system that applicants may access.

TR 242

TR 243

The system should provide the ability to assign the next available plate number available in inventory.

The system should provide the ability to renew a registration and issue a new plate type at the same time.

Commercial Registration Processing

TR 244

The system should allow for fees based upon standard Fee tables for Colorado and the other current 58 jurisdictions.

TR 245

The system should allow users with specific access levels to update the fee tables as needed.

TR 246

The system should allow commercial vehicle data associated to a customer to be modified by approved staff.


TR 247

TR 248

TR 249

TR 250

TR 251

TR 252

TR 253

TR 254

TR 255

TR 256

TR 257

The system should calculate and display fees per weight group based on weight, number of months, unladen weight, age of vehicle, purchase date, taxable value, if MSO and apportion percentage.

The system should allow staff to “undo or rework” supplements in case of data entry error and allow staff to make necessary corrections.

The system should produce a weekly report that details differences in fee paid versus fee due, and make the report available on demand.

The system should produce reports of completed supplements that do not finalize and go to the clearinghouse file.

The system should be able to calculate the registration fees, when there is a change to the registration.

The system should be able to find the registration using a plate number or other customer data such as: employer number, state assigned employer number and DOT number, when searching for a registration.

The system should archive customer accounts that an authorized user determines are “Invalid.’

The system should provide a method to issue consecutive account numbers for customers.

The system should indicate customer or vehicle activity for other commercial programs (e.g., Permits, UCR/SSRS,

Hazardous Materials/Waste, IRP, Full Fee, USDOT, PRISM,

CVIEW, POE, and vendors that provide records).

The system should automatically populate data fields from other internal/external systems.

The system should display all possible duplicate vehicle and customer records and information about those duplicates.


TR 258

TR 259

TR 260

TR 261

TR 262

TR 263

TR 264

TR 265

TR 266

TR 267

The system should allow for override capabilities to create a new customer record and/or change information on existing record on duplicates. The system should require the override user to be different from the initiating user.

The system should be able to determine eligibility for participation in the installment payments (monthly or quarterly) and calculate plan amounts.

The system should include a payment status field to indicate that fees are “due” or “paid.” This field should appear at the vehicle, customer level, and fleet level.

The system should allow the authorized user to choose tabledriven or manually entered distance.

The system should allow for the issuance of a hazardous materials permit or the renewal of a permit that may be associated only with a single vehicle.

The system should capture all information from a CO permit

(e.g., Hazardous waste, Overlegal, Temporary) and endorsement (e.g., Hazmat) application.

The system should allow endorsements to be created from previous year information.

The system should generate summary and detailed (individual unit) invoices, printed or electronically sent, and formatted.

The system should accept adjustments to the transaction level fees that print on the invoice. Adjustment codes and descriptions should be table-driven and updatable by authorized users.

The system should allow text to print on the invoice that can be modified by an authorized user.


TR 268

TR 269

TR 270

TR 271

TR 272

TR 273

The system should automatically populate jurisdiction from previous registration but allow user to enter type of distance reported (e.g., actual, first-year estimated, second-year estimated) and allow authorized user manual entry.

The system should allow generation of a report to indicate the number of vehicles to be operated at the table-driven distances, and multiply that figure by the number of vehicles, to establish the estimated distance for that jurisdiction.

The system should allow IRP personnel with the appropriate security level to update default mileage information per jurisdiction, apportioned and non-apportioned fees, Canadian

Exchange rate, vehicle make, fuel, color, etc.

The system should generate a report for applications/accounts that have not finalized.

The system should auto populate vehicle information when a

Colorado title number has been provided.

The system should generate a reject letter notification to the applicant when the application does not meet the requirements established by the business rules.

ROL Processing

TR 274

The system should be able to record the receipt and details of a

Release of Liability.

TR 275

The system should be able to provide the Release of Liability information to the requesting customer, when a transfer of title transaction is requested.

TR 276

The system should associate a Release of Liability with the seller’s vehicles title, current or historic and allow for a user interface to update vehicle record.


TR 277

The system should allow an authorized user to find, enter and update Release of Liability information on the vehicle record by an authorized user with the proper system security role.

Collect Fees

TR 278

The system should calculate the fees and taxes due, depending on the service or product transaction type, service delivered, vehicle class/sub-codes, and excise tax, etc., based on address, empty weight, taxable value, vehicle year, fuel type, business date, special tax districts, purchase date, tax class, etc.

TR 279

TR 280

The system should allow for the exemption of taxes and fees, partial exemption of taxes and fees, or collection of alternate amounts from standard calculations of taxes and fees based on business rules for vehicle types, plate types, owners that meet specific exemption qualification.

The system should allow for the retaining of paid vehicle taxes and fees into a holding account for defined owners and vehicles allowing that owner to draw from the account to pay taxes on fees on any vehicle owned by that person pursuant to defined business rules.

TR 281

TR 282

TR 283

The system should allow for the alternate calculation of taxes and fees from standard calculations for vehicles and owners that meet specific alternate calculations as defined in business rules.

The system should provide the ability to perform payment verification for debit, credit and cash cards in a Payment Card

Industry (PCI) compliant manner.

The system should post financial entries for collected payments and allow for multiple tender types per payment transaction and multiple service transactions per payment transaction.


TR 284

TR 285

TR 286

The system should be able to calculate and prorate the difference between the fees, when a customer requests to transfer registration and the new vehicle will have a different registration type. Credits given for adjustments must be reported separately on financial reports.

The system should calculate and include the transfer fees, when a transfer of a registration is processed.

The system should be able to calculate any additional program fees, when a registration is processed with a specialty plate.

TR 287

TR 288

TR 289

The system should calculate and record the monthly clean screen emissions test fees collected by each county. (Clean

Screen payments are collected for the contractor.)

The system should be able to carry over any remaining applicable value from the original vehicle registration, when an applicant requests a new plate type.

The system should be able to track calculated fees and compare that to the amount of collected fees.

Vehicle Record

TR 290

The system should be able to capture all information on a vehicle abandonment report.

TR 291

TR 292

TR 293

TR 294

The system should be able to identify the most recent title produced.

The system should automatically maintain a history of vehicle ownership.

The system should interact with GenTax and the Public Utilities

Commission’s website to validate Tow Carrier via “T” number and FEIN numbers to ensure all systems match

The system should allow 3 rd

parties, authorized by the DMV

(i.e. Tow Carriers, Law Enforcement etc.) to be able to search

VIN’s via the IDS (or other online) system


TR 295

TR 296

TR 297

TR 298

TR 299

TR 300

TR 301

TR 302

TR 303

The system should interface (along with IDS or other such systems) with GenTax in the billing of authorized 3 rd

parties for searches performed.

The system should allow for online payments from approved 3 rd parties for searches that they conducted.

The system should allow a vehicle record to be retained including branding information if a CO titled vehicle is moved out of state.

The system should facilitate the capture of brand information as a part of the vehicle record.

The system should capture and retain, at a minimum, canceled, declared salvage, rebuilt, flood damaged, and non-reparable or abandoned status on a vehicle record.

The system should retain a history of all vehicle title or registrations information associated with a vehicles VIN.

The system should be able to change the title’s status to nonrepairable, when a vehicle is declared as non-repairable.

The system should capture and record on the vehicle record the type of title transaction that was processed (e.g., new, out-ofstate, CO title transfer, name change, lien change, duplicates, correction, etc.).

The system should be able to create transitional ownership document transaction on the vehicle record.

Resolve Issues

TR 304

The system should allow for an authorized user to maintain a table of approved transfer rejection reasons.

Req. ID Produce Title and Registration, Issue Plate

TR 305

TR 306

The system should allow an authorized user to create a fake vehicle record, including VIN, for investigative purposes.

The system should require that creating a fake vehicle record requires the involvement of two authorized users.

Issue Title

TR 307

TR 308

TR 309

TR 310

TR 311

TR 312

TR 313

TR 314

The system should generate an application for title document

(with status) as a receipt to customers and have the ability to reprint.

The system should have the ability to print a “no-fee” new, revised, or duplicate title.

The system should provide for information formats to be in accordance with the Universal Title layout recommended by the

American Association of Motor Vehicle Administrators

(AAMVA) and the National Highway Traffic Safety

Administration.

The system should have the ability to generate a new unique title number and title type (e.g., salvage, rebuilt from salvage, etc.) for user-designated service transactions.

The system should capture system-assigned identification number when issuing a title.

The system should be able to print a user-defined number of brand designations on a title.

The system should provide for the printing of titles ‘on demand’ at authorized locations and in a batch mode.

The system should be able to detect and provide an alert when an out-of-state Secure and Verifiable Identification (SVID) number is provided which does not conform to the numbering conventions of that state.


TR 315

The system should provide an alert when user-defined vehicle(s) are registered at the same address. The threshold for the number of vehicles necessary to trigger an alert should be able to be user-defined.

Title Notifications

TR 316

The system should be able to send notices to title holder customer when corrections are made.

TR 317

TR 318

The system should be able to notify owners listed on the title, when a title is sent out to a lien holder.

The system should be able to notify owner and any lien holders, when a request for lien sale is received from a vehicle possessor.

TR 319

TR 320

The system should generate a rejection notice for any rejected title application.

The system should be able track title application rejection communications associated with a vehicle record.

Title Publication/Printing

TR 321

The system should be able to reprint the title with any corrections.

TR 322

The system should be capable of processing a request for an over-the-counter duplicate title by an authorized user.

TR 323

TR 324

The system should be able to print a title, both individually and via batch.

The system should have ability to print title certificates using different authorized user roles (e.g., county office, HQ).


TR 325

TR 326

The system should allow the owner to initiate a secure Internet transaction to print a paper title at business-defined location, and should allow them to specify the party and address to which it is to be mailed, when the owner with a clear title has opted to have the department maintain a clear title electronically.

The system should be able to generate a canceled title report which can be printed or e-mailed securely.

Issue Plate

TR 327

TR 328

TR 329

TR 330

TR 331

TR 332

TR 333

TR 334

TR 335

The system should provide the ability to maintain a list of characters that are unavailable either because they are currently assigned or they have been deemed inappropriate.

The system should allow for configurable number of characters per plate.

The system should record the plate image – including alphanumeric separator characters to be able to reproduce the plate as issued.

The system should be able to check for unique plate characters without a separating alphanumeric character by class/sub-class.

The system should be able to assign active plates to a vehicle registration.

The system should allow the customer to choose the characters on any plate background to preview the finished product before applying.

The system should have the ability to define valid options for vanity plate characters by plate background, as Vanity plates can be on any background.

The system should display plate issuance requirements (i.e., pre-certification, donation to non-profit, etc.).

The system should reserve vanity plate characters.


TR 336

TR 337

The system should support eligibility requirements by plate type.

The system should be able to accept and process, Special

Interest, Special Program, and Vanity plate application/requests via a Web-based service.

Registrations/Plate Notifications

TR 338

The system should be able to generate a notification to be sent to the registrant when a registration is canceled.

TR 339

TR 340

The system should be able to notify the applicant electronically and/or by the creation of a rejection letter, when a request for personalized plates is rejected.

The system should be able to create mailing labels for plates ordered.

TR 341

The system should track the license plate assigned date, including transfers to replacement vehicles. When the plate becomes aged, the system should prompt and require new plate issuance.

Registration/Plate Publication/Printing

TR 342

The system should be able to print registration with voided decals or registration forms that do not contain a decal.

TR 343

TR 344

TR 345

The system should be able to reprint the registration the same day as the registrant requested, if the reprint requires no changes.

The system should provide the ability to print registration and licensing documents on specified and/or controlled forms.

The system should enable the county office to print or reprint the registration with or without embedded decals on same day, when there are no changes required to a registration.


TR 346

TR 347

The system should be able to generate a temporary registration, as required.

The system should provide the ability to record compliance information, e.g., emissions inspection, safety inspection and

VIN verification data.

Person with Disability Application

TR 348

The system should allow for the electronic submission and/or intake of a customer-completed application for new or renewal of persons with disability.

TR 349

The system should allow for the electronic submission and/or intake of a customer/physician-completed request for a name change, change of address or other applicable information changes for persons with disability.

TR 350

TR 351

The system should provide the ability to denote the disability type for the owner.

The system should issue the documents associated with the disability for renewal based on the disability type denoted on the owners’ record.

TR 352

TR 353

TR 354

TR 355

TR 356

The system should limit the number of placards or handicap plates that can be issued to an individual based on statutory and business requirements.

The system should allow for handicapped minors’ information to be placed on the parents or guardians record.

The system should be able to verify the identification in the application matches the identification in the DL system.

The system should be able to verify the physician number via the Department of Regulatory Agencies (DORA).

The system should provide the ability to denote permanently disabled on both the driver’s license record and the actual driver’s license, as well as the customer file.


Persons with Disability Placard

TR 357

The system should have the ability to issue, track, report, and maintain data pertaining to multiple types of placards both at the customer and the vehicle level.

TR 358

TR 359

TR 360

The system should have the ability to issue and track permanently disabled person placards.

The system should have the ability to issue and track temporarily disabled person placards.

The system should track organizations that qualify for permanent disabled person placards.

TR 361

The system should generate different renewal notices for placards based on the need for medical professional verification or self-certification.

TR 362

The system should provide the ability to track placard information issued by other states and agencies.

TR 363

The system should provide the ability to flag if a CDL holder is assigned a person with disability placard so the system can alert the CDL Unit.

TR 364

The system should provide for a Health Care Provider to certify persons with disability eligibility via the DMV Web site through their account.

TR 365

TR 366

The system should provide the ability for the customer photograph to be placed on the Persons with disability Placard.

The system should have the ability to cross check vital statistics death records, to verify that the applicant is not deceased.

Req. ID General

TR 367

TR 368

TR 369

TR 370

TR 371

TR 372

TR 373

TR 374

TR 375

TR 376

The system should provide end to end inventory management tracking from point of manufacturer to issuance. Inventory is to include but not be limited to license plates, registration products

(both serialized and non-serialized), and secure forms,

The system should upload inventory manufacturing files, placing the inventory into the correct location (county or state) in a status that indicates the inventory is available for issuance,

The system should allow the county or state to move the inventory from an “available” status to a “ready for issuance” status.

The system should issue inventory from the “ready for issuance” status when performing title and registration transactions that require that inventory.

The system, upon issuance of inventory, should mark that inventory as issued.

The system should allow for issuance of non-physical inventory

(eg. Lien reception numbers, title numbers, etc.)

The system should allow for other inventory status changes based on user security level. Other inventory status should be, but is not limited to Destroyed, Lost, Stolen, Audit Adjustment, etc.

The system should update inventory based on the status pursuant to business rules (i.e., if marked Destroyed, remove from available and ready for issuance status),

The system should permit movement of inventory between locations.

The system should provide inventory management reports based on established business rules,

Req. ID General

TR 377

TR 378

TR 379

TR 380

TR 381

TR 382

TR 383

TR 384

TR 385

TR 386

TR 387

The systems inventory management system should track inventory by inventory type, plate type, status, issuance, by location, by date and allow for reporting of inventory tracking.

The system should allow for dual registrations on vehicles where statutory or regulatory compliance is met (e.g.,

Emergency Vehicle, Light Truck, etc.)

The system should allow for registration of emergency vehicles pursuant to business rules.

The system should allow for the registration of inoperable collector vehicles pursuant to business rules.

The systems should allow for the registration of special event vehicles and license plates pursuant to business rules.

The system should be a knowledge based system that allows for live interaction between the user and the system (e.g., information boxes that appear when user hovers over a field, knowledge base manual, etc.),

The system should allow for users with appropriate levels to perform bulk record queries and bulk record exports/reports.

The system should tie check/cash processing directly to the record(s) for which the payment was remitted, including bulk or multiple transactions.

The system should allow for free form letter writing that can be associated with a record (e.g., reject letter, request for additional documents, short check, etc.).

The system should allow for file load of issued temporary registration permits issued by dealers and entered into the system by tolling authorities.

The system should provide for bulk title processing when appropriate (e.g., dealer titles).

Req. ID General

TR 388

TR 389

TR 390

TR 391

TR 392

TR 393

TR 394

TR 395

TR 396

TR 397

The system should marry scanned/archived documents with system records and allow for the user to access those scanned/archived documents while viewing or performing a transaction on a record.

The system should allow for title and registration history search functions and transactions.

The system should allow for purging of records due to tax and sales.

The system should allow for vehicle owners whose vehicles are not in Colorado (students, military, etc.) to update their vehicle insurance and/or emissions status in order to allow them to register/renew their vehicles.

The system should provide error reporting which allows authorized users to correct records/transactions based on business rules.

The systems should provide for a “year of manufacturer” registration process.

The system should permit another state to provide electronic file of out-of-state title deletes that can be uploaded to automatically delete/update records.

The system should allow for handicap plates and placards to be marked as confiscated and follow confiscation notification and processes defined by business rules.

The system should allow for handicap plates and placards to be marked as revoked and follow revoked notification and processes defined by business rules.

The system should allow for handicap plates and placards to be marked as judgment and follow judgment notification and processes defined by business rules.

Req. ID General

TR 398

TR 399

TR 400

TR 401

TR 402

TR 403

TR 404

TR 405

TR 406

TR 407

The system should allow for covert title, registering, and plating of vehicle for law enforcement covert operations.

The system should allow for the ability to produce a renewal notice/document for covert registrations to the law enforcement entity and not the covert record name/address.

The system should allow registration numbers to be marked as reserved for auction pursuant to business rules.

The system should not allow a registration number reserved for auction to be issued until release from the reservation by users with specific system levels.

The system should associate vehicle owners with qualifiers that permit them to have a plate or registration product (i.e., Purple

Heart recipient, handicap, auction winner, etc.).

The system should not allow a transaction to be completed on a plate or registration product unless the owner that is associated with the qualifier remains an owner of the vehicle.

The system should allow users with specific system levels to mark plates and registration products as not active and prevent the users from selecting them for issuance/registration.

The system should allow for canned and ad hoc report generation (i.e., monthly registered vehicle by plate, legislator requests, etc.).

The system should allow for secure file transfers between CO

DOR and other entities upon approval of DMV. DMV should be able to initiate and complete these file transfers without OIT involvement.

The system should allow for regular scheduled file transfers pursuant to business rules and contractual agreements.

Req. ID General

TR 408

TR 409

TR 410

TR 411

TR 412

TR 413

TR 414

TR 415

TR 416

TR 417

TR 418

The system should generate, in addition to required documents

(i.e., registration receipt, title, etc.), a transaction receipt detailing all taxes and fees associated with the transaction performed, where the taxes and fees are transmitted, the statutory references for the taxes and fees, and whether they were collected or exempted.

The system should be “real time” and eliminate any batching or delay in posting transactions.

The system should allow for any reports to be exported to spreadsheet and word-processing type applications.

The system should allow online renewals for customers that have free/exempt plates such as Disabled Veterans and Purple

Heart, etc.

The system should allow online renewals for government agencies that have been issued government plates.

The system should allow Colorado citizens to apply and pay for a personalized plate through an online application process.

The systems should allow for reports to print by entering date range of report.

The system should include a custom report writer with the ability to query data on multiple criteria.

The system should be structured to allow for selection of specific transactions and ensure proper documentation is provided by the customer.

The system should be able to print required documents for customer completion at any point during the transaction.

The system should allow for the calculating of sales taxes based on an Address Confidentiality Program (ACP) participant’s actual address, then immediately overwrite the address with the

ACP address.

Req. ID General

TR 419

TR 420

TR 421

TR 422

TR 423

TR 424

TR 425

TR 426

TR 427

TR 428

The system should allow SMM 2% Rental companies to apply online to participate in the monthly SMM 2% rental reporting requirements.

The system should allow counties to access their SMM 2% rental reports from the online SMM 2% rental reporting requirements.

The system should require operator to acknowledge a checklist of items, ensuring all business requirements are met before allowing the transaction to be completed pursuant to business rules (i.e., all require documents received and validated when completing a bond transaction etc.)

The system should provide document recognition of scanned documents and check to ensure document-specific business rules are being met. System should flag those documents that are non-compliant.

The system should flag title applications for audit, based on business rules and statistical requirements.

The system should have a training/document area where authorized users can set-up links and upload documents and videos.

The systems should allow for different registration receipts/cab cards to be printed based on vehicle/owner pursuant to business rules.

The system should have the capability to flag a non-repairable title (i.e. for Parts Only) electronically.

The system should be able to notify owner, operator (County), and any lien holders when record status changes to real property.

The system should be able to change the title’s status when declared real property.

Req. ID General

TR 429

TR 430

TR 431

TR 432

TR 433

TR 434

TR 435

TR 436

TR 437

TR 438

TR 439

The system should be able to capture all branding information

(i.e., Tow BOS, Junk, Purge Ad Valorem, Salvage, and Rebuilt from Salvage etc.).

The system should be able to redact personal information, according to established CO business policies, Statute, rules and federal regulations.

The system should be able to capture operator, date, and time when a search is performed.

The system should maintain a historical account of each vehicle and all transactions performed on that vehicle pursuant to business rules.

The system should allow for historical record searches to be performed.

The system should capture report information to collect

Urban/Rural Registration tax information.

The system should capture report information to collect Federal

Highway Tax information.

The system should allow for the bulk issuance of temporary registration permits and low power scooter decals to licensed dealers capturing the issuance to the licensed dealer for each temporary registration permit and low power scooter decal.

The system should update the record for the dealer issued temporary registration permit or low power scooter decal from the bulk issued dealer name to the individual’s name who the dealer sold the vehicle too.

The system should allow for real time record searches and data queries.

The system should allow for accessing electronically provided documents, reference guides and commercial manuals and guides.

Req. ID General

TR 440

TR 441

TR 442

TR 443

TR 444

TR 445

TR 446

TR 447

TR 448

TR 449

The system should calculate and collect back ownership taxes and fees owed and assess them pursuant to business rules.

The system should allow for authorized customers to interface and request an estimation of taxes and fees due on their vehicle.

The system should maintain and track credits due to customers and allow that customer to apply those credits to subsequent transactions pursuant to business rules.

The system should track credits and refunds issued and maintain a tracking system/log of when credits are used and to which vehicle(s) they are applied.

The system should allow for individual taxes and fee credits or refunds to be selected instead of applying the credit or refund to the total amount.

The system should allow for supervisor and manager level report generation (i.e., transactions by clerk, types of transactions completed for a period, money collected by a specific clerk, transaction duration times by clerk/work unit, etc.).

The system should allow for a robust change management process that documents and tracks changes made and logs user acceptance testing completed and the results of those tests.

The system should associate documents and correspondence provided to an owner to the vehicle record and allow the clerk to access those documents and correspondence when needed.

The system should provide an itemized receipt to the customer of the transaction.

The system should allow for “online chat” capabilities to the help desks (i.e., OIT help desk, emissions, etc.).

Req. ID General

TR 450

TR 451

TR 452

TR 453

TR 454

TR 455

The system should allow for non-vehicle specific electronic communications (i.e., county to a dealer, doctor to a county for a PWD applicant, county to county, etc.).

The system should allow for a printable temporary registration permit.

The system should have the ability to barcode items, documents and transactions and allow the clerk to scan a barcode to bring up the record and perform a transaction of it.

The system should allow for transactions to be performed in counties that the vehicle is not located at (cross county transactions) allowing for that vehicle to remain associated with the original county and collect and distribute taxes and fees based on established business rules to both the original county and the transaction county.

The system should interface with county maintained tax locators.

The system should allow for a master (all county maintained tax locators combined) tax locator to be maintained and updated, allowing State and cross county transactions to access and interface with the master tax locator.

International Registration Plan - IRP

Req. ID International Registration Plan - IRP


IRP 1

IRP 2

IRP 3

The system should allow each fleet to contain vehicle groups set by body type, combined GVW for each selected jurisdiction.

IRP 4 The system requires a physical location address in Colorado.

IRP 5 The system requires established place of business in Colorado.

IRP 6

IRP 7

The system should allow the estimated distance table to be updated regularly.

The system should provide security login levels with access levels.

IRP 8

IRP 9

The system should allow users to search on parameters such as

IRP account number, FEIN, SSN, USDOT, Registrant Name,

Registrant Address, VIN, Title Number.

The system should be fleet based with all vehicles in the fleet expiring on same day.

The system should allow the Colorado state and all 58 jurisdiction fees tables to be updated regularly.

The system should allow the Canadian Exchange Rate table to be updated monthly.

IRP 10 The system should allow each fleet to follow USDOT rules

IRP 11 The system should receive PRISM data from FMCSA.

IRP 12

The system should provide registration data to CVISN, CO Port of Entry, CBI/NLETS, and vendors.

IRP 13

The system should provide online registration for carriers providing access to their fleet with security and validations built in.

IRP 14

The online system should allow submission of application; original, renewal and supplements.

IRP 15 The system should allow for installment plan per rules.


IRP 16

The system should allow for payment online via credit card, echeck, ACH. Credit card transactions must be PCI compliant.

IRP 17

The system should allow a clearinghouse file, transmittal report and recap reports created per date range.

IRP 18 The system should provide IRP data to the Field Audit group.

IRP 19

IRP 20

IRP 21

IRP 22

IRP 23

IRP 24

IRP 25

IRP 26

The system should post payments made from cashiers and online within 4 hours.

The system should allow and track fee credits from deleted vehicles.

The system should prorate credits each month until zeroed out or registration expires.

The system should allow vehicles to be added, changed, VIN corrections, deleted, moved between groups, renewed, not renewed and suspended.

The system should allow adding jurisdictions, changing combined GVW on select jurisdictions, plate and tab replacements, cab cards, USDOT safety updates on supplements.

The system should calculate fees; provide fee breakdowns per jurisdictions, per vehicle, both apportioned and non-apportioned fees, and determine apportionment percentage. The system should use proper Canadian exchange rate, rounding rules for each jurisdiction and any special calculation for selected jurisdictions.

The system should provide an inventory management module that allows inventory to be added; plates per type, month and year tabs with year tab numbers tracked, electric vehicle decals.

The system should provide proper inventory assignment dependent on tasks performed, and provide a list of inventory to staff when performing issuance.


IRP 27

The system should allow a certain access level to manually assign available plate, tabs, and decals.

IRP 28

IRP 29

The system should provide method to enter or select estimated table mileage for fleet.

The system should determine emissions area location requirement for fleet address.

IRP 30

The system should allow for emissions CEC or extension data entry per vehicle.

IRP 31 The system should provide validation for HVUT per vehicle.

IRP 32

IRP 33

IRP 34

IRP 35

IRP 36

IRP 37

IRP 38

IRP 39

The system should provide a billing statement per supplement including all fees listed and voucher for cashiers.

The system should allow for temporary and for permanent credentials

The system should allow the online user to print credentials online when available.

The system should allow staff to open new fleets and close fleets when necessary.

The system should allow staff to combine fleets with all groups and vehicles.

The system should provide a renewal packet three months in advance or current registration expire with important information to direct carrier to correct any necessary action before renewal can be worked (such as USDOT issues, reporting period and payments past due).

The system should provide a secure method to allow online users to electronically send in necessary documentation with submitted application.

The system should allow a certain access level to set up a database query.


IRP 40

IRP 41

IRP 42

The system should provide a method to message online users with pertinent information.

The system should allow for online third party (agent) access to

IRP accounts with permissions provided by both account owner and agent.

The system should allow users and agents to manage access to their online login account.

IRP 43

The system should allow staff users to view and assist online user login accounts.

IRP 44 The system should allow easy navigation between screens.

IRP 45

The system should allow staff to add comments per fleet, per taxpayer.

IRP 46

The system should provide validations for emissions, HVUT, title with list per VIN.

IRP 47

IRP 48

The system should provide a data verification between title and vehicle data.

The system should request reason when jurisdictions selected are not contiguous, and if GVW weigh is over 10% difference between jurisdictions.

IRP 49

IRP 50

The system should require additional documentation if user enters their own estimated mileage for proof of value.

The system should not allow for PO Box on physical location address.

IRP 51

IRP 52

The system should require a police report attachment if lost plate indicated.

The system should allow for staff to view out of service daily report and suspend vehicle. The system should send a letter for all suspended vehicles.

IRP 53 The system should allow for back dating specific ownership tax.


IRP 54

IRP 55

IRP 56

IRP 57

IRP 58

IRP 59

IRP 60

IRP 61

IRP 62

IRP 63

IRP 64

The system should convert current data into new database format which includes all application history, calculations, plate history, and billing and payment history.

The system should allow for audit netting in the clearinghouse file each month.

The system should generate the clearinghouse file at 12:01 a.m. on the 1 st

day of each month.

The system should allow staff to make changes to an original or renewal application and when finalized the supplement number will be zero.

The system should establish the 12 month registration based on supplement zero. (Supplement zero must be finalized before any subsequent supplements are allowed to finalize.)

The system should allow multiple supplements to be opened by multiple users following supplement zero but must build upon each supplement as they complete. In other words each supplement builds upon what was allowed in the last completed supplement going forward.

The system should provide a bar code on credentials for law enforcement.

The system should provide a summary of each application, history of who worked the application, PRISM census to assist staff, and a vehicle summary that listed all vehicle status in fleet.

The system should provide a search per VIN, plate, owner.

The system should provide a daily list from FMCSA of out of service vehicles and Carriers.

The system should allow staff to un-suspend vehicles when issues are remedied.


IRP 65

IRP 66

IRP 67

IRP 68

IRP 69

IRP 70

IRP 71

IRP 72

IRP 73

IRP 74

IRP 75

IRP 76

IRP 77

The system should allow staff to transfer accounts from one taxpayer to another.

The system should provide a method to add changes from current.

The system should sync current registration period with the open renewal application while asking user if this operation is desired.

The system should carry over credits from one supplement to the next until credit is zero or fleet registration expires.

The system should apply credits properly such as Ownership tax credit apply to ownership tax on added vehicle and registration and age fees apply to registration and age fees on added vehicle.

The system should not allow carry over credits if the jurisdiction does not allow for carry over credit.

The system should not allow carry over credits for a GVW weight reduction.

The online system should not allow user to open multiple supplements.

The online system should provide user with list of needed action items such as titles, HVUT, Emissions, Established place of business, and other required documents.

The system should provide user with useful error message that they can understand and fix if necessary.

The system should prioritize payments to registrations first followed by other tax groups.

The system should allow select user to create a temporary cab card if account is hung up in process.

The system should not send files to the clearinghouse table until application is in approved status.


IRP 78

The system should not allow any supplements to process until supplement zero has been approved.

IRP 79

The system should provide a payment schedule and letters if installment plan selected. The letters should be mailed to taxpayer 30 days in advance of payment due date.

IRP 80

The system should track the installment plan bond until bond expire date or paid in full.

IRP 81 The system should calculate the payment schedule per statute.

IRP 82

The system should notify staff of an installment plan default on payment to resolve.

IRP 83

IRP 84

IRP 85

IRP 86

IRP 87

IRP 88

IRP 89

IRP 90

The system should allow authorized staff to edit any data in a submitted application. Corrections may require a recalculation of fees.

The system should allow the user to sort columns on any report or summary table.

The system should notify the online user when credentials are available by email.

The system should notify the online user when documents are due, payments are due, and credentials are available by email or e-messaging on system.

The system should provide online help to users such as popup windows with definitions or instructions.

The system should allow for copy and paste of data between fields.

The system should perform match and conversion of clearinghouse data to the system’s data criteria.

The system should be capable of accommodating the automatic population of IRP data with matched clearinghouse data.


IRP 91

IRP 92

IRP 93

IRP 94

IRP 95

IRP 96

IRP 97

IRP 98

IRP 99

IRP 100

The system should be capable of accommodating the data entry for Federal IRP registration information (e.g., PRISM, CVIEW,

HVUT).

The system should allow for different registrant (account owners) with a different registration owner and USDOT responsible for safety for IRP registrations.

The system should provide a single point of entry for or Full

Fee/IRP transactions, specific to customer and vehicle data.

This should include a “mass renewal” data entry component.

The system should include at the vehicle level, the vehicle registration cancellation (i.e., delete transfer, transfer of plate and credit fees to new vehicle, wrecked vehicle, etc.) date, and date license plate was returned or transferred to another vehicle.

The system should calculate and display the distance reported

(Full Fee – Vehicle level) or actual mileage or per-vehicle average distance reported (IRP – Fleet level).

The system should support credential printing standards set by

DMV, including the embedded sticker software for IRP and Full

Fee.

The system should provide the ability to interface with an IRP/

IFTA COTS application to facilitate the issuance of IRP registrations.

The system should interface with IRP clearing house based on standards defined by the IRP clearing house.

The system should include an audit module for the entry of IRP audit data, calculation of audit findings and list results on the monthly IRP transmittals, in accordance with IRP mandates.

The system should support guidelines and regulation of the

International Registration Plan (IRP).


IRP 101

The system should have a customer code to indicate if the account has IRP e-carrier access and/or is handled by a service agent.

DMV Financial Processing

Req. ID Reconcile Cash Drawer

Transactions & Fees Administration

F 1

The system should provide for a System administrator role which will be able to add, delete and modify a table of possible

DMV transactions, with each transaction having an associated fee to be charged to the customer. For example: Reissued

Driver’s License, No Fee; New Drive License, etc.

F 2

F 3

F 4

The system should be assign a unique transaction ID number and print receipt numbers when fees are paid for a transaction.

The system should track all transactions associated with revenues collected for the purpose of allocating overhead costs in estimating profit per transaction. The allocation of overhead costs would occur outside the system, and within general ledger/cost systems.

The system should be able to maintain financial tables which should provide business rules for fines, default values and penalties for each transaction type.

F 5

The system should have the ability to track inventory items and the financial flow of inputs and outputs at a detailed level.


Fees Calculation

F 6

The system should be able to automatically calculate the fees for vehicle registrations based on rules for each vehicle type.

F 7

The system should be able to compute tax when a vehicle title or registration application is processed.

F 8

The system should be able to compute local option tax when a vehicle title or registration application is submitted.

F 9

F 10

F 11

F 12

F 13

F 14

F 15

The system should be able to account for any prepaid tax when a title or registration application is processed for a private transaction from a seller who has a tax number and be able to indicate the amount of any difference between the calculated and pre-paid excise tax.

The system should calculate the transfer fee for a registration that is transferred from one owner to another.

The system should maintain a table of fees exemptions for county, state, and federal agency.

The system should be capable of automatically calculating amount due, credits, and refunds on any customer or vehicle transaction.

The system should allow the retention of historic fees and be able to reproduce calculated fees based on a date range.

The system should maintain a history of fees, both assessed, voided, and paid.

The system should be able to capture the payment of all special fees associated with DMV transactions.

Fee Waiver

F 16

The system should capture authorized user and approver information (who, what office, when, reason code), for the requestor and approver, on all waived fees.


F 17

Fee Override

F 18

The system should provide authorized users and override approvers with a table-driven list of reasons/classifications to justify overriding a fee assessment.

F 19

The system should allow authorized users, with appropriate role and access and supervisor approval, to waive or modify fees.

The system should allow authorized users to input a custom reason/classification to justify overriding a fee assessment.

Cash Management

F 20

The system should calculate the fees and taxes due, depending on the service or product transaction type, service delivered, vehicle class/sub-codes, and tax (for original registration only), etc.

F 21

F 22

The system should provide the ability to perform payment verification for debit, credit and cash cards.

The system should post financial entries for collected payments and allow for multiple tender types per payment transaction and multiple service transactions per payment transaction, including electronic transfer of funds through, e-check, ACH and credit card.

F 23

F 24

F 25

The system should support the cash drawer reconciliation process and the preparation of a combined office deposit, at the detailed transaction level and in summary.

The system should employ or support a double entry accounting system and interface with the State accounting system.

The system should adhere to the Department of Revenue’s cash handling policies.

Reconciliation


F 26

F 27

The system should support the reconciliation of all tender types in the cash drawer to the transactions completed.

The system should support electronic/online reconciliation of accounts by all appropriate offices/agents.

Cash Drawer Payments and Receipts

F 28

The system should capture payment confirmation information, including: Amount, Date and Tender Type (e.g., Cash, Check, and Credit Card) and associate each transaction with the authorized user ID.

F 29

F 30

The system should have the ability to interface with check verification services to ensure that funds are good and there is not a history of bad checks written on the bank account.

The system should produce a single invoice for all transaction performed during a customer interaction.

Point of Sale

F 31

The system should provide the ability for the sale of nonstandard items as a point of sale menu option.

F 32

F 33

The system should allow for receipt of funds from DMV sales in designated locations including but not limited to county offices, Ports of Entry, and DMV Headquarters personnel.

The system should capture financial transaction for DMV services from external POS.

F 34

The system should provide the ability to receive payment for

DMV services via the mail.

Payment Types

F 35

The system should allow fee collection by table driven set of payment types (e.g., credit card, cash, check).

F 36

The system should maintain a table of acceptable payment types by county office.


General Financial

F 37

The system should support an audit trail to track adjustments and access of applications, including:





All adjustments should include a reason/comment for the adjustment.

Check and balances for fraud prevention e.g., over certain amount needs supervisor approval or certain types of adjustments need management approval.

F 38

The system should support the electronic fund posting at time of, receives total for all transactions and should submit payment immediately before transactions will transmit.

F 39

F 40

The system should support the automated posting directly to accounts, including bank interface for direct deposit accounts.

The system should support double entry accounting system to allow for tracking debits and credits such as partial payments,

NSF’s/bad checks and associated fees for accurate accounts receivable.

F 41

F 42

The system should support the ability to allow for new fees

(additional plates) etc.

The system should support allocated distributions at the time of transaction based on amount collected.

Req. ID

Document Imaging

Reconcile Office Revenue

Req. ID Reconcile Office Revenue

F 43

F 44

The system should support the scanning of transaction and other documents at the DMV offices for transmission to, processing and filing at headquarters.

The system should support a mechanism for display of or prompting the DMV agent for the documents required for a given transaction, at the time of the transaction.


F 45

The system should support DMV configurable, table driven office codes.

F 46

F 47

The system should produce a report that shows the reconciliation of revenues collected to transaction counts over a defined period of time. E.g., daily, weekly, monthly, yearly, etc.

The system should be capable of recording a cash receipt number when fees are paid for any transaction.

F 48

F 49

The system should itemize using time input parameters

(daily/weekly) on all cash received and deposited for revenue operations authorized user.

The system should allow reporting on any transaction that had fees waived.

F 50

The system should allow reporting on customer accounts for violation of state excise tax fraud (non-payment) and send notice to defined authorized user for human review.

General

F 51

F 52

The system should be able to receive data from remittance equipment used to deposit, endorse and encode DMV checks as well as uploading client payment data.

The system should be able to support or receive data from an imaging system.

Req. ID Reconcile Office Revenue

F 53

The system should provide reconciliation reports that are generated to indicate the data was received from other systems that transmitted information. These reports may be related to deposits, revenue distribution, or just client data.

Req. ID Reconcile DMV Revenue State-wide

Cash Management

F 54

The system should support the cash drawer reconciliation process and the preparation of a combined office deposit.


F 55

The system should support the reconciliation of the aggregated

DMV-wide view of recorded service transaction counts with the fees collected from all sources and recorded at all DMV “points of sale.”

F 56

The system should support the daily/monthly reconciliation of

DMV recorded service transactions with bank deposits and credit/debit card settlements.

F 57

F 58

The system should produce a report that shows the reconciliation of revenues collected to transaction counts over a defined period of time. E.g., daily, weekly, monthly, yearly, etc.

The system should be capable of recording a cash receipt number when fees are paid for any transaction.


F 59

F 60

F 61

The system should itemize using time input parameters

(daily/weekly) on all cash received and deposited for revenue operations authorized user.

The system should allow reporting on any transaction that had fees waived or where the transaction was voided.

The system should allow reporting on customer accounts for violation of state tax fraud (non-payment) and send notice to defined authorized user for human review.

Adjustments

F 62

The system should support the creation of revenue adjustments for financial, bank, and system transactions at the customer and summary.

F 63

F 64

The system should support the reclassification of funds and the creation of necessary revenue accounting entries to credit revenue accounts and debit liability accounts in order to maintain a correct customer account balance.

The system should provide the ability to interface with an automated accounts receivable function to run the statements for a defined period of time.

F 65

The system should provide the ability to reject refund requests.

F 66

F 68

The system should maintain an audit trail of adjustments, including but not limited to, agent ID, reason for adjustment, and approval thresholds.

Installment Plans

F 67

The system should be able to determine eligibility based on business rules for installment payment plans and calculate amounts.

The system should allow fee accounts for customers to charge permits to and be billed monthly.


F 69

F 70

F 71

The system should allow customers with commercial vehicles to maintain positive balances on a customer account.

The system should allow customers with commercial vehicles to be billed monthly.

The system should send notification to customers with negative balances in their customer account after a configurable number of days.

MV Investigators Reconciliation

F 72

The system should track all entries of fees collected by Motor

Vehicle Investigators with the control number of cash receipt by types.

F 73

The system should be able to print cash receipts for Motor

Vehicle Investigators receipt moneys from customers.

F 74

F 75

F 76

The system should track Motor Vehicle Investigator cash receipts and the corresponding control numbers from the time of issue by Financial Operations until receipt is used to collect fees from customers.

The system should report all money collected and reconcile weekly with deposits made by individual Motor Vehicle

Investigator.

The system should be able to calculate and categorize all fees payable by the customer and produce receipts as required.

Refund

F 77

F 78

The system should provide the ability to provide refunds to a customer by the same payment type tendered during the originating transaction.

The system should utilize work flow process when issuing a refund to obtain approvals.


F 79

F 80

F 81

F 82

F 83

F 84

The system should allow refund transactions processed at DMV

Headquarters from the DMV system to the state accounting system to automatically create refund documents.

The system should maintain table overpayment tolerances for refund processing.

The system should require refund amounts over a threshold to receive additional approvals.

The system should produce a monthly report for all refund activity.

The system should grant refunds processing by authorized user role, for all refund activity.

The system should be able to track, inquire and report on refunds, and the status of refunds.

Printing

F 85

F 86

The system should provide the ability to print a receipt for all transactions.

The system should be able to print forms of billings that are not the invoice and have a print preview feature.

Reporting

F 87

F 88

F 89

The system should provide transaction summary reports for batch entered work.

The system should be able to provide transaction and revenue reports by cash drawer, location, transaction and tender type.

The system should have the ability to generate a consolidated master report over a defined time period payments received listing forms of payment including check, cash, credit and debit card payments etc. This transaction report will show the breakdown by register or location and transaction type details.


F 90

F 91

The system should be able to tally a running total of fees for the authorized user when the authorized user is entering more than one application from the same customer.

The system should have the ability to count a transaction even though a fee was waived in order to facilitate profitability analysis. E. g. Counting a waived driver’s license reinstatement fee in the transaction count even though DMV did not collect a fee.

Notifications

F 92

The system should generate automated collection letters

(dunning) for NSF checks, permits billed on account, etc.

F 93

The system automatically generate notifications for customers who are late in paying recurring DMV transactions (e.g., payment plans, permit renewals, registration renewals).

Non-Sufficient Funds (NSF)

F 94

The system should have the ability to produce an insufficient payment notification letter for services rendered that have been paid with non-sufficient funds.

F 95

F 96

The system should have the ability to assess fines and penalties on customer or vehicle transactions that are NSF as stated by

CO code and allow for suspension of services as needed.

The system should have the ability to automatically make correcting entries if non-sufficient funds are received.

Interface Functionality

F 97

The system should have a customer transactional database that interfaces daily cash and revenue transactions with the DMV’s financial accounting system(s).

F 98

The system should allow authorized users to electronically transmit customer and vehicle records for tax violations.


F 99

The system should provide an interface with the DMV’s financial accounting system(s).

Req. ID Distribute DMV Revenue

Revenue Distribution

F 100

The system should support the summarization and reporting of

DMV fund-level financial activity to the appropriate agencies and offices.

F 101

F 102

The system should track the organizational plates issued, process collections of fees and automatically distribute funds to proper accounts.

System should support adjustments to distributions, including those already completed.

Distribution and Accounting

F 103

The system should be able to record funds generated for all groups by plate and registration renewal (e.g., college, veterans, environmental).

F 104

F 105

The system should maintain a table of fee distributions which will associate moneys received on each transaction to distribution of funds to other agencies or all appropriate groups/entities.

Revenue distribution, including funds, accounts and formulas/percentages should be table driven and administered by the CO DOR.

Req. ID Distribute DMV Revenue

F 106

F 107

The system should be able to generate reports on revenues and distributions.

The system should support interfaces to all appropriate agencies, entities and accounts for the purpose of revenue distributions.

Req. ID

General

F 108

F 109

F 110

F 111

F 112

F 113

The system should allow for the generation of reports that indicate the number and type of transactions performed.

The system should allow for a number of statistical reports to be generated regarding the number and type of transactions

(including rejection rates).

The system should allow supervisors and managers to enter into a table the “standard” amount of time to perform specific transactions for metric purposes.

The system should allow for the tracking of workload inventory and backlog based on metrics established by business rules.

The system should allow for assignment of “back office” work, based on workload inventory and backlog reports and be able to be adjusted by managers and supervisors as needed.

The system should be able to accurately track the number of customers serviced, the wait time of those customers, the duration of transaction time, number of touches with the same customer and abandoned rate.

Hearings Division

Req. ID Hearings

H 1

H 2

H 3

H 4

H 5

H 6

H 7

H 8

H 9

H 10









The system should provide typical docketing functionality for the CO DOR hearings Division including, but not limited to:

 Administrative hearing scheduling.

Assignment dates.

Time tracking.

Calendaring.

Scheduling of hearing officers and hearing rooms.

The system should be able to generate notification letters to multiple parties for all hearings and associate them in the file.

The system should be able to collect and record information concerning motions, subpoenas, and other events for a specific case number.

The system should create a database of hearing officer decisions, which is searchable by case number and/or text.

The system should allow access by authorized Hearings

Division employees to appropriate data in the DMV systems concerning driver information, driver license, and vehicle registration.

The system should only allow authorized DMV employees to view Hearing Officer orders and notes.

The system should provide tracking functions for the purpose of auditing.

The system should be capable of providing information to customers in multiple languages, primarily English and Spanish.

The system should provide the ability for customers to serve themselves online as much as possible (e.g., with a case number and login, a person could view their case information).

The system should interface with the current Hearings Division

IVR system.

Technical Business Requirements

Req. ID Auditing and Reporting

Publication/Reports

T 1

The system should have the ability to utilize an ad hoc reporting tool that allows trained users to create reports from data.

T 2

T 3

The system should have a report batch monitor that controls the number of reports that may be run at a given time for each server.

The system should have a report scheduler that can schedule reports to be automatically run at user-defined times.

T 4

The system should provide the ability to load a spreadsheet / word processed or other file onto the system that is then available as a bulletin to advise of system updates and other information.

T 5

T 6

The system should support reports, both of real-time and snapshot data that are publishable to an intranet or the Internet.

The system should maintain reprint request details for DMV products (title, registration, credential, reports) to include user, date, time, and location and allow this information to be accessible by authorized users.

T 7

T 8

T 9

The system should provide authorized user with appropriate access to see reports on transactions started, in-process, and completed for staff in their area of responsibility by user, role, office and time parameters.

The system should provide the ability to reprint reports on demand.

The system should be able to receive a report from each office and assign it to a work team.

Req. ID Auditing and Reporting

T 10

T 11

T 12

T 13

T 14

The system should distribute reports by an electronic interface or allow for printing to paper.

The system should provide the ability to generate tag reports.

These reports will include, but not be limited to: Tags/decals issued by office by month, tags issued by tag type across one or more offices.

There should be regular, scheduled reporting such as end of day, accounting/financial, dealer inspection, permitting, and others; as specified in the various functional requirements.

There should be ad hoc reporting requirements, where users need to create one time reports or saved reports on an as needed basis.

To facilitate the above activities, there should be a standard reporting tool for all reports. This tool should be used against all data sources, for creating both scheduled and ad hoc reports, including flexibility in formats and document types (e.g., XML,

CSV, DOC).

Req. ID Messaging and Communications

Messaging

T 15

The system should provide the ability for users to communicate externally to include Internet mail, etc.

T 16 The system should provide e-mail integration capabilities.


T 17

T 18

T 19

T 20

T 21

T 22

T 23

T 24

The system should provide the ability for individuals with the appropriate level of access to disseminate alert messages to a grouping of users.

The system should be capable of providing or interfacing to a correspondence subsystem for the generation of correspondence and other documents required in the DMV business work flow.

The correspondence subsystem should be able to generate letters, documents and other DMV configurable correspondence that aligns with DMV business rules and automatically fill the configurable correspondence with the appropriate data from the system.

The system should be capable of logging correspondences for auditing purposes. The log should include information on sender, data/time, and topics. It is desirable that the logging activities will be automated.

E-mail contents and fax images should be stored in a multimedia database. This data should be associated with customers, and can be accessed and retrieved as part of a business transaction.

E-mails should be based on existing State of Colorado e-mail systems.

There should be a programmatic interface with the fax system.

Outbound fax should be automatically created and sent as a result of DMV processes – such as notifications, or customer requests through Internet or IVR.

There should be a programmatic interface with the e-mail system. Outbound e-mails should be automatically created and sent as a result of DMV processes – such as notifications, or customer requests through Internet or IVR.


T 25

To, The system should be able to store and maintain customer email addresses and fax numbers in the customer database, to accommodate outbound correspondence by authorized users.

Req. ID Law Enforcement Information

Law Enforcement Inquiries

T 26

The system should provide vehicle color(s) in responses to registration queries.

T 27

T 28

T 29

T 30

T 31

The system should provide secondary identification number data (labeled “engine or other ID number” on the vehicle title form) in responses to registration queries.

The system should provide registration queries based on this secondary identification number.

The system should provide the ability to query vehicle registration files by partial license plate, partial VIN, vehicle descriptors (e.g., make, model, style, year range, color) city or county of registration, name or address of registered owner, or any combination of these fields.

The system should provide the ability to query vehicle registration files by SSN, ITIN, or unique personal identification number assigned to the registered owner.

The system should provide the ability to return the complete social security number in driver’s license queries from law enforcement agencies.

Req. ID

T 32

T 33

T 34

T 35

Law Enforcement Information

The system should provide the capability to look at the prior title history of a vehicle.

The system should provide the ability to query driver’s license records by Soundex name as well as city or county of residence.

The system should provide the ability to query driver’s license records by address.

The system should provide links or access to tables containing code values used by DMV in driver’s license and vehicle registration files.

Req. ID Document and Image Management

Document Imaging

T 36 The system should support the scanning of transaction and other documents at the DMV offices for transmission to, processing and filing at headquarters.

T 37

T 38

The system should support scanning and coding (e.g., bar, QR, etc.) images of all documents at the time of transaction, for electronic tracking.

The system should support an automated image locator by transaction and or office with various search criteria.

Document Management

T 39

The system should provide a technical mechanism to support the collection and scanning of documents related to motor vehicle transactions and attaching to the customer account.


T 40

T 41

T 42

T 43

T 44

T 45

T 46

T 47

T 48

Documents collected at remote offices (field offices, POS,

DMV offices) should be captured and transmitted, either in realtime or store-and-forward, to central repository.

Scanned document images, together with related data, should be assigned and routed through work flow processes

The system should provide the capability for creation of outbound electronic forms that combine data from operation database and image database (signature image).

The system should have the capability to place documents in a work queue on a case-by-case basis. The documents can then be viewed and processed on a “near time” basis.

The system should allow dealer title applications (or other documentation as defined by business rule) to be captured and scanned using OCR solutions.

The system should provide the ability to capture all components of an ID/Driver License card and any other motor vehicle transaction.

The system should allow for capture of data from AAMVA compliant machine readable information (e.g., bar code, QR code, etc.) technology on all DMV forms.

The system should be designed to accommodate the reading/scanning of machine readable information (e.g., bar code, QR code, etc.) technology on documents that meets

AAMVA standards for coding and content.

The system should allow an operator to pick from table driven lists of authorized source documentation that may be submitted by an applicant for a DMV product (e.g., titling, registration, or credential).


T 49

T 50

T 51

T 52

T 53

T 54

T 55

T 56

The system should be able to create, print, electronically transmit, and track all outgoing correspondence (letter, e-mail, fax). Document should be digitally connected to the appropriate record.

The system should be able to capture, store, link to the appropriate record and retrieve the digital images of applications and documents. Documents may consist of multiple pages (e.g. creation and maintenance of driver and/or vehicle records).

Paper documents (incoming and outgoing), photographs and signatures should be scanned for image capture. Scanning should be performed:





At field offices when business transactions occur, using flat-bed scanners.

Central repository (possibly mail room) when document arrives. The system should be able to accommodate future document handling automation and preparation for highspeed scanning.

For document scanning at field offices, the system should transmit document images to a central image database.

The system should provide the option for image transmission not transmitting in real time, due to band-width and response time constraints, and instead during off-peak periods.

The system should provide the option of transmitting images in real time. Users at different locations should have the capability of viewing the images in real time together.

The system should provide the ability to re-scan a document if the quality of a scan is not acceptable.

The system should provide a flexible set of indices that can be defined for the documents. After capturing, the documents should be indexed prior to storing.


T 57

T 58

T 59

T 60

T 61

T 62

T 63

T 64

T 65

T 66

T 67

The system should store scanned documents online for the duration business rules defined retention period. After the online retention period expires, the documents can be archived and removed from online viewing.

Once a document has been moved to “off-line” storage, the document management system should retain a location indicator which will show an operator the documents current location.

The system should store document images at a business practice defined minimum resolution.

The system should provide the ability to retrieve all documents within the business defined retention period using one of the indices that are defined and entered for the document.

The system should allow only authorized users to access documents and all transactions should be logged.

The system should provide the capability to automatically redact and un-redact PII based on user profile.

Documents should be associated with corresponding data records (e.g., credentials, dealers, vehicles, titles).

Document images should be able to be displayed inside a browser.

Document images should be stored in an industry standard format (e.g., TIFF, JPEG).

It is desirable to be able to add notations, in free text form, to a document image.

The following document properties should be supported: multipage documents, double-sided documents, and different document sizes.


T 68

T 69

T 70

T 71

T 72

T 73

Together with machine readable information (e.g., bar code, QR code, etc.) on the printed forms, an OCR system should have the capability to automatically recognize capture, and index data input on scanned forms.

All documents issued by the DMV that are generated by the

DMV application system should contain a unique identifier that can be used to identify the customer, type of document, and variable data contained within the document. This information should be stored in a character sequence and in a machine readable information (e.g., bar code, QR code, etc) format.

All inbound documents containing machine readable information (e.g., bar code, QR code, etc.) formatted information should be scanned for machine readable information (e.g., bar code, QR code, etc.), including the use of hand-held scanners. Scanning should be performed:





At business defined location, documents should be batched together for high-speed scanning with code reader.

During data entry of incoming documents, entering unique identifier number should bring up on the screen information stored in the machine readable source (e.g., bar code, QR code, etc.), including customer information, document information, and any variable data that are captured.

Inbound and outbound fax data should also have the option to be captured, stored, associated, and retrieved in the same manner described above.

Inbound and outbound e-mails should also have the option to be captured, stored, associated, and retrieved in the same manner described above.

Other electronic documents, including Spreadsheets, PDF files, and other electronic files, should also have the option to be stored, associated and retrieved in the same manner described above.


T 74

T 75

T 76

T 77

T 78

T 79

T 80

T 81

T 82

Select DMV staff should have assigned work queues. An employee can examine his work queue at any time and review any outstanding assignments that will require their attention.

Some activities can be assigned high priority – either automatically through business rules, or manually assigned by employees. Priority transactions should be placed on the front of a worker’s work queue and an alert (e.g., e-mail, pop-up, text message) can be sent to them and retained with the record.

Based on the status of a transaction and pre-defined business rules, a transaction should be automatically routed to the next individual. Authorized personnel can also override the automatic routing, and assign the work to a specific employee.

It is desirable that there will be capabilities to define teams and departments. Through this definition, workload can be distributed among employees. Supervisors within a department should have the ability to make specific assignments.

Through the assignment, an employee should be able to automatically access all information associated with the transaction. This information should include transaction records, document images, or other types of related data such as fax, or e-mail.

The work flow system will integrate with other DMV system components (e.g., title, credentialing, motor carrier).

All transactions (manual or automatic) and associated work flow should be logged. Reports should be available on transactions, work flow, efficiency and effectiveness.

Data in the operational database should be archived, at fixed intervals, based on retention dates specified in the business rules management requirements.

The system should be able to return an archived record to active status by an authorized user, if necessary.


T 83

T 84

T 85

T 86

T 87

T 88

T 89

T 90

T 91

T 92

T 93

Associated electronic documents should also be archived based on the same retention dates.

The archival medium should be a standard and robust product, example includes: optical disk, magnetic tape.

Once archived, the data should be erased from the online storage.

There should be automated procedures in place to perform these archival activities. Archival should be based upon predetermined rules specified to the Document Management system.

The system should include the archive functionality to include frequency of access to tier two and three storage.

The archived information and document should be organized so that they can be accessed and retrieved within business defined rules.

The system should be capable of managing documents based on

DMV’s business rules drive records retention schedule.

The system should allow authorized users to override DMV’s retention schedule. When an override is put in place the user will be required to identify a reason for it. The system should notify the document management system manager of the override.

There should be an ability to easily create forms. There should also be facilities to create machine readable information (e.g., bar codes, QR code, etc.) on the forms.

There should be capabilities to modify an existing form, using the same facilities.

There should be policies and procedures for forms approval process, where an authorized user can accept or reject a created or modified form.


T 94

T 95

T 96

T 97

T 98

T 99

T 100

T 101

Only authorized users can create, modify or approve forms.

There should be an audit trail on these activities.

There should be facilities to manage multiple versions of the same form, with indicators identifying current versions, prior versions, and expired versions.

There should be facilities to index and manage metadata about each form (e.g., what database it draws information from or stores data to).

There should be a central database for all these forms, with functions for efficient indexing, storage and retrieval of forms.

The forms should be stored in standard document formats (e.g.,

PDF, reasonable backwards capabilities).

There should be capabilities to handle different document types as form templates, including spreadsheets and word processed documents.

There should be application capabilities to retrieve these forms as overlays for printing. The retrieved form should be merged with data from the integrated operation database and/or document image database (e.g., signatures and photos), to be incorporated as part of outbound notices/correspondences to customers.

There should be application capabilities to use these forms as templates to be displayed under a Web browser. Once retrieved these electronic forms can be:







Used as a template for the user to enter data.

Merged with data from the integrated operation database and/or document image database to provide user with form viewing and modification capabilities.

Downloaded to a workstation in PDF format for local data entry and printing functions.


T 102

All usage of these forms – for printing and electronic access – should be logged in an audit trail, together with the actual data that are displayed, entered or printed. For some predefined forms types, the filled-in form will be imaged and stored in the image repository.

Images and Archives

T 103

The system should have the ability to access photos and other image information stored in any other DMV repository.

T 104

T 105

The system should have the ability to access other documents or images stored in a specified repository.

The system should have the ability to retrieve and route images stored in a specified repository.

T 106

The system should have the ability to retrieve and route other documents or images stored in a specified repository.

Functional Requirements Response Table

Colorado DRIVES – Functional Requirements – Response Tables

Related documents

Products

Support

Functional Requirements Response Table

Colorado DRIVES – Functional Requirements – Response Tables

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib