DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

113
State of Nevada Brian Sandoval Department of Administration Governor Purchasing Division Jeff Mohlenkamp Director Greg Smith 515 E. Musser Street, Suite 300 Carson City, NV 89701 Administrator NEVADA STATE PURCHASING DIVISION REQUEST FOR PROPOSAL (RFP) DEVELOPMENT FORM FOR IT PROJECTS Note: If you have questions regarding completion of this form, please contact the Procurement Staff Member that will be working with you on the RFP. DEPARTMENT/AGENCY INFORMATION Department: Nevada Department of Motor Vehicles Agency/Division/Bureau: Nevada Department of Motor Vehicles Budget Account Number: 4716 Agency Number: 810 Program (if applicable): NA Anticipated Contract Amount: $ 109,446,534 MM Anticipated Contract Term: FY2016 - FY2021 Authored By: Alexander Dore Title: Sr. Enterprise Architecture – Security Architect Phone Number: (310) 863-9142 Fax Number: 775.684.4563 Email Address: [email protected]; [email protected]; Mailing address: 555 Wright Way Carson City, NV 89711 How many contract originals does your agency require for signature? 3 Name Title Troy Dillard Director Rhonda Bavaro Deputy Director Names and Titles of individuals that will sign the contract: RFP Title: Nevada Department of Motor Vehicles System Modernization Previous RFP Number, if applicable: RFP #: Issued by: Previous Purchasing Contact, if applicable: Previous RFP or Contract if done by agency: Please attach a copy for reference Anticipated BOE Date: September/October 2015 Is the project funded? Yes: No: X Is any portion federal funds? Yes: No: X Does this project require a Technology Investment Request (TIR)? Yes: X No: If so, has it been approved? Please provide a copy of the approval. Yes: X No:

Transcript of DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

Page 1: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 1 of 113

State of Nevada Brian Sandoval Department of Administration Governor Purchasing Division Jeff Mohlenkamp Director

Greg Smith

515 E. Musser Street, Suite 300 Carson City, NV 89701

Administrator

NEVADA STATE PURCHASING DIVISION

REQUEST FOR PROPOSAL (RFP) DEVELOPMENT FORM FOR IT PROJECTS

Note: If you have questions regarding completion of this form, please contact the Procurement Staff Member that will be working with you on the RFP.

DEPARTMENT/AGENCY INFORMATION

Department: Nevada Department of Motor Vehicles Agency/Division/Bureau: Nevada Department of Motor Vehicles Budget Account Number: 4716 Agency Number: 810 Program (if applicable): NA Anticipated Contract Amount: $ 109,446,534 MM Anticipated Contract Term: FY2016 - FY2021 Authored By: Alexander Dore Title: Sr. Enterprise Architecture – Security Architect Phone Number: (310) 863-9142 Fax Number: 775.684.4563 Email Address: [email protected]; [email protected]; Mailing address: 555 Wright Way Carson City, NV 89711 How many contract originals does your agency require for signature? 3

Name Title Troy Dillard Director

Rhonda Bavaro Deputy Director Names and Titles of individuals that will sign the contract:

RFP Title: Nevada Department of Motor Vehicles System Modernization Previous RFP Number, if applicable: RFP #: Issued by: Previous Purchasing Contact, if applicable:

Previous RFP or Contract if done by agency: Please attach a copy for reference

Anticipated BOE Date: September/October 2015 Is the project funded? Yes: No: X Is any portion federal funds? Yes: No: X Does this project require a Technology Investment Request (TIR)? Yes: X No:

If so, has it been approved? Please provide a copy of the approval. Yes: X No:

Page 2: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 2 of 113

RFP DEVELOPMENT INFORMATION INSTRUCTIONS

Complete all information required in the following tables. If not applicable or required, please put “Not Applicable” in the appropriate section. The information provided below will be included in the appropriate sections within the RFP. Follow the numbering format in the RFP template to identify section headings, subheadings, etc. Attach additional information if applicable. A PDF version of the IT RFP Template is embedded here for your reference in completing this form.

Page 3: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 3 of 113

PROJECT OVERVIEW This section should provide a brief synopsis of the project/requirements.

The section should include an overview of the project to include such things as anticipated project start and end dates, administering agency, any other pertinent information.

DMV Intent and Modernization Background: The Prime Directive The prime directive of this RFP is to clearly step out an integral informational roadmap that will allow an informative group of solution vendors and integration specialists to digest and present a best of class response as to the specifics as to what the Nevada DMV requires to purchase a complete systemic (IT) overhaul.

The Desired Response The responses must treat and improve on the current methods as to how DMV manages its business. The responses must elaborate the proposed reduction or eradication of, where possible, manual processes and record keeping, unless otherwise mandated by business continuity constraints. Where possible the proposals must also demonstrate where the transition from a manual to automated work-flow optimizes the business requirements. Lastly the proposals must demonstrate the deployment of fully automated and consolidated transparent services, providing customer secure best-in-class products and services. Absorbing Legislative Mandates

The DMV will present a list of future features that it is challenged to implement, should the legislature agree, where these modernizations must be designed as placeholders should the law change. Some examples would be the enlarging of the PII dataset by the inclusion of fingerprints on the driver license or the discrete collection and storing of phenotyping for each unique customer profile. The Nevada DMV is a mature yet forward thinking organization that is fully prepared to enter the era of fast paced technology development and business evolution.

Business Approach This RFP sets out a framework to promote a seamless approach to business and technology capability integration. The RFP does not dictate the technology components only the environments such as SOA and MDM, standards and capabilities required; where the approach is to define the WHAT not the HOW. With that in mind the DMV requires a system that will meet above all the desired business evolution coherently and cohesively. This direction must be mirrored in the solution vendor responses.

Risk Management The DMV will institute a security principled risk management policy which will be based on a future repurposed DMV master security model based on the concept of an enterprise within an enterprise. This RFP will require the vendor to tackle future risk by raising the security bar from minimum to maximum requirements based on the inclusion of additional international, U.S. federal government and recognized institutional security measures and standards enhancing the Nevada state security standard. Unfortunately due to the current cyber threats and vulnerabilities minimum tolerances are no longer acceptable. The proposed legacy modernization transition is an opportunity to ensure a sustainable and leading edge risk mitigated environment. The selected solution vendor must present the most holistic assurances that stem any and all vulnerabilities from an end-to-end architectural perspective.

This RFP though focusing on technology modernization and the benefits from social networking, mobility and clouds will emphasize the absolute need for enhancing security countermeasures and assurances based on current measurable and immeasurable threats and vulnerabilities.

Page 4: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 4 of 113

PROJECT OVERVIEW This section should provide a brief synopsis of the project/requirements.

The section should include an overview of the project to include such things as anticipated project start and end dates, administering agency, any other pertinent information.

The High Bar Attaining zero tolerant security is the intended goal of this RFP. This aim alone is the most compelling goal for government and the private sector related to the stewardship of sensitive and private information in our technology age. Indiscriminate criminal and malicious hacking has reached new unforeseen heights and more advanced elements such as Anonymous have successfully breached internets, extranets and intranets that were once thought of as safe government organizations as well as wealthy institutions in the public sector. As we see on the international front line cyber-attacks are beginning to be thought of a serious act of malicious aggression, if not close to an act of terrorism.

DMV though requiring zero tolerance also recognizes that zero tolerance for security risk is doubly problematic in an environment in which information must be shared. There is a recognized deep and unavoidable tension between information sharing and information security. The solution vendor’s responses must allow the DMV to evaluate the mechanisms that mitigate this tension, some being unavoidable, in order that senior DMV leadership can decide what degree of security risk is acceptable and under what circumstances in return for the advantages of broad based information sharing.

Without doubt the DMV’s information systems are prime targets for internal and external threats; nevertheless, the only approach that truly provides ZERO risk is one that destroys all information as soon as it is collected or that otherwise makes information entirely inaccessible to anyone1. Irreproachable Stewardship

The DMV as an agency is additionally the steward of the consummate intellectual property that has become the PII record of every documented citizen of Nevada that has applied for an identity card and the driver license. The proposed new DMV system will ensure that PII is a collection of unique properties of identification that only pertain to one individual; no duplicates are acceptable. It is therefore the prime function and responsibility of DMV to ensure the uniqueness, security and integrity of this information. In order to secure PII DMV has defined a requirement for a vault-type security model in its reference architecture. The vault or bar-code repository must be de-coupled from any other agency interface and that any publication to other agencies, internally or with the DMV customer will be handled within the prescribed boundaries of this maximum security model. Caution as a Best Practice

Therefore the Nevada DMV in this RFP will take the most cautionary approach in line with zero tolerance verses the current and evolving threats; anything less being unacceptable. In order to accomplish this risk-averse strategy the DMV, as set out in this RFP is highly motivated to building its own secure enterprise that would be seamless within the existing state enterprise, yet still working hand in hand with EITS; being transparent where necessary. This is further outlined in the security section of this RFP.

Optimizing Time through Agility Competing vendors must be acutely aware that the time projected to complete the technology transition falls within a five year program. Where possible the main business of the DMV should be optimized by being brought on line iteratively rather than in a waterfall process. Therefore the vendor propositions must somehow manage the constantly evolving and competing technologies.

1 A Review of the FBI's Trilogy Information Technology Modernization Program

Page 5: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 5 of 113

PROJECT OVERVIEW This section should provide a brief synopsis of the project/requirements.

The section should include an overview of the project to include such things as anticipated project start and end dates, administering agency, any other pertinent information.

The initial technology offering must attain a steady state of equilibrium, factoring in the most collaborative and ready to market solutions. The solution vendors must also plan for the inclusion of new technology where appropriate, where new apps are secure, easily integrated and certified.

Critical Path This RFP addresses the critical path and challenging infrastructural predicament the DMV as an organization finds itself in. The DMV in this RFP has decided to present a more business centric view of its organization aspiring to attract the right mix of best-in-breed technologies to replace the security and economic risks involved by continuing to operate a legacy environment that is long overdue for an overhaul. The legacy technology currently in production that maintains DMV services has eclipsed its usefulness and the DMV’s ability to support an old COBOL language environment at a low cost has sunset. The continued addition of enhancements on top of an original 40 year old legacy as well as repeated attempts to wrap the legacy and add a more modern façade has reached the point of no return. DMV must now rapidly ascertain the point of least resistance to work its way out of the legacy through modernization.

Equilibrium The strategic aim of this RFP is to secure the desired state of systemic overhaul equilibrium, yet still observing conventional wisdom to manage risk. For all outside appearances the DMV will continue to maintain its current services per the legislative record to date. This RFP unveils the proposed modernization process. As this legacy modernization process matures into the planning stage the hope is that the selected vendor will be on hand to inform and assist the legislative body to visualize how leading edge technology may improve future service capabilities, reduces costs and manage risk. DMV Heavy Load & Burden

The Nevada Department of Motor Vehicles (DMV) currently does business with over two million people a year, which could possibly reach three and a half to five million in five years. Today DMV also manages at least 15% of the State operating revenues. With increased system efficiency and optimized workflow the new DMV system could improve the collection of revenues by merely balancing the books and in all probability could markedly surpass the collectable revenues currently reported annually. With the current and unforeseeable fluctuation in U.S. and global economics, the changes in immigration flux, birthrates, migrations from high costs of living and urban saturation, the opportunities for new technology parks such as the Tesla move to Nevada, it is still unrealistic however to project meaningful statistics beyond 2020. Therefore the high end requirement capacities to handle increased data, data traffic, transactions, security as well as increased online and mobile access can only be projected for the future based on the current demographic data forecasts available. DMV Today & Tomorrow Today the DMV is a broad and diverse enterprise agency that not only issues driver licenses, registers vehicles, and produces vehicle titles, it manages motor carrier permits including the collection of fuel taxes as well as issuing a limited amount of small business licenses. This markedly differentiates the Nevada DMV from its other State DMV agencies. Even though the Public Safety sector has recently been spun off from the original DMV organization, the DMV today still maintains and transmits a considerable quantity of Personally identifiable information or PII (as used in U.S. privacy law and information security, is information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context) pertaining to law enforcement, the judiciary and public health that under no circumstances can this information be compromised by the new system. The DMV currently interacts with more customers than any other State agency and produces the most important government secure identity for the State of

Page 6: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 6 of 113

PROJECT OVERVIEW This section should provide a brief synopsis of the project/requirements.

The section should include an overview of the project to include such things as anticipated project start and end dates, administering agency, any other pertinent information.

Nevada; the identity card and the driver license.

The People of DMV

This project is not just about technology and computers; it is really about the dedicated DMV civil servants who are asked to perform a rigorous task on outdated equipment. It is about their futures and careers; it is also about making the customers of the DMV feel that their state taxes are being well spent, that there is true accountability and that the DMV services that the state offers are of the highest quality and will attain to become one of the best DMV agency models in the nation.

Special Instructions

Contract award is dependent on legislative funding and Board of Examiners (BOE) approval. Upon funding and BOE approval, the project is anticipated to start on or before October 1, 2014 and end by June 30, 2020.

Transformation

The DMVfully intends to radically move away from the legacy constrained BPM model that it currently endures by deploying its technology on a mainframe “Z” architecture platform. The current product layer encompasses a broad and highly diverse product array. Due to the inherent architecture from the maiframe Z/OS even with modern wrappers the stovepipe model is unavoidable as even web services inherit the initial segregation of services based on the mainframe LPAR internal structure.

Page 7: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 7 of 113

PROJECT OVERVIEW This section should provide a brief synopsis of the project/requirements.

The section should include an overview of the project to include such things as anticipated project start and end dates, administering agency, any other pertinent information.

DMV - Current State Legacy BPM

Transformation Scope

The intended transformation will vastly improve the BPM integrating once separated services and products into a seamless dynamic optimized supply and value chain BPM. The Vendor’s architecture must address this transformation and apply the dynamics needed to fully integrate the BPM. Additionally the BPM model must evolve from a 2D presentation of data to a 3D presentation of business intelligence. Below are the major thresholds to overhaul presented at the enterprise level. The vendor will find the component layer more explicitly described in the function requirements later on in this RFP.

Intended Division of Labor The DMV’s organizational aspirations are, where possible, to create a seamless and cohesive set of enterprise services. The major enterprises of the intended system for the purpose of this RFP are expressed as services driven by a business process layer of requirements as detailed in the appendices (???) of this RFP. The major DMV services are, but not limited to, tax collection, finance, document control, customer relationship, eligibility determination, privilege issuance, secure stewardship, public safety and public education.

The Process and Service layers shall be managed from a business intelligence driven DMV governance and compliance management to be developed from metric driven service level agreements and service level objectives as determined in appendix III. The binding force of the intended processes and services shall be the BPM layer, or in its technology form the ESB. The protection of DMV assets will be managed from a zero-tolerance security model.

Page 8: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 8 of 113

PROJECT OVERVIEW This section should provide a brief synopsis of the project/requirements.

The section should include an overview of the project to include such things as anticipated project start and end dates, administering agency, any other pertinent information.

Finance

The DMV intends to completely overhaul its concepts of core GL financal model ensuring financial compliance and increased automation within the integrated core finance processes.

The DMV shall require an intuitive and user friendly portal managing a transaction based GL reporting and revenue distribution system that interfaces with the State Treasurer and State Controller. The DMV will continue to collect revenues in the same form as it does today; at the counter, on line or mailed in, reserving the possibility, as secure interfaces mature, to adopt newer forms, such as Apple-Pay™ for example.

The new GL hub will be required to better optimize current resources and streamline financial operations, complying with the State Accounting Policies and Procedures as well as all Nevada statutes as they relate to revenue collection and distribution, including but not limited to financial reporting requirements. The intended GL system shall plan to streamline and automate financial operations with the State Treasurer and State Controller while complying with state regulations. The DMV GL portal will deliver core financial business intelligence to gain real-time insight into overall performance within US GAAP and State standards.

Additionally the core financial process shall integrate processes from various applications for a single version of financial truth operating in multiple geographies in Nevada.

Suggested Financial MDM GL Hub

Customer Relations and Business Process The DMV also anticipated in building a much improved citizen and customer outreach and knowledge

Page 9: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 9 of 113

PROJECT OVERVIEW This section should provide a brief synopsis of the project/requirements.

The section should include an overview of the project to include such things as anticipated project start and end dates, administering agency, any other pertinent information.

interchange by delivering a dynamic customer relationship management (CRM) portal as well as radically redesigning the business processes to achieve dramatic improvements in organizational performance. DMV requires that CRM refers to not only to the software application but the business strategy as well and the vendor shall make every attempt to ensure a homogenous enablement of both to ensure ease of maintenance of unpredictable adaptations of the business process and its subsequent deployment. The DMV shall require a CRM that includes methods, strategies, software and network capabilities that vastly improve the DMV to resource manage and organize its counter and online relationships with its customers from issuance to audit. The CRM shall allow the dynamic collection and distribution of data into all the core business areas. The CRM system must be a readily maintainable implementation of reliable interactive systems processes and procedures.

Sustainability DMV additionally has aspirations to meet sustainability to enforce protective measures on the environment. DMV requires to implement a rule based electronic document and template managed library system creating as much of a paperless environment where hard copy documents are not required; barring what is mandated by law and constrained by disaster recovery needs. Unavoidably, some paper forms will still remain outside of the systemic environment until legislative changes are made in the future.

Enterprise Overview of Seamless Processes and Services

Major Stats (Current and Growth)

Nevada DMV Demographic Growth Rate Projection

State Demographer Growth Rate 2015 2016 2017 2018 2019 1.30% 1.30% 1.30% 1.00% 0.90%

Note: Growth for FY18 & FY19 is based on the Demographers most recent 20 year projections including projected growth as a result of Tesla.

Page 10: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 10 of 113

PROJECT OVERVIEW This section should provide a brief synopsis of the project/requirements.

The section should include an overview of the project to include such things as anticipated project start and end dates, administering agency, any other pertinent information.

Nevada Verification of Lawful Status Projection

VLS Projected Growth Rate Year VLS Charged Transactions

2013 (Actual) 129,800 2014 (Actual) 130,008

2015 (Projected) 131,698 2016 (Projected) 133,410 2017 (Projected) 135,145 2018 (Projected) 136,496 2019 (Projected) 137,724

Note: Growth for FY18 & FY19 is based on the Demographers most recent 20 year projections including projected growth as a result of Tesla.

Nevada DMV Total Transactions (TXN) Growth Rate Projection

Year Total TXNs 2013 (Actual) 8,430,476

2014 (Actual) 8,669,517

2015 (Projected) 8,782,221

2016 (Projected) 8,896,390

2017 (Projected) 9,012,043

2018 (Projected) 9,102,163

2019 (Projected) 9,184,083

Note: Growth for FY18 & FY19 is based on the Demographers most recent 20 year projections including projected growth as a result of Tesla.

Nevada DMV Total AAMVA Transactions (TXN) Growth Rate Projection

AAMVA Projected Growth Rate

Year SSA Charged Transactions

PDPS Charged Transactions

2013 (Actual) 190,907 2,699,543

2014 (Actual) 447,777 2,797,944

2015 (Projected 453,598 2,834,317

2016 (Projected) 459,495 2,871,163

2017 (Projected) 465,468 2,908,489

2018 (Projected) 470,123 2,937,573

2019 (Projected) 474,354 2,964,012

Note: Growth for FY18 & FY19 is based on the Demographers most recent 20 year projections including

Page 11: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 11 of 113

PROJECT OVERVIEW This section should provide a brief synopsis of the project/requirements.

The section should include an overview of the project to include such things as anticipated project start and end dates, administering agency, any other pertinent information.

projected growth as a result of Tesla.

GOALS AND OBJECTIVES

If applicable, this section should provide high level goals and objectives of the project. This can be incorporated in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section.

High-level Agency Goals:

• All Department processes will be reengineered to maximize technology and resources.

• All existing vendor contracts will continue to be used with no changes identified at this time.

• All existing vendor interfaces will be developed and tested to existing specifications; unless the vendor is upgrading or using new supported systems.

• The implementation strategy will depend on the awarded vendor selection and funding model approved for system modernization.

Customer Environment

• To prioritize, to fully implement and expound upon the Governor’s mandates in the context of DMV modernization.

• To improve customer service allowing the DMV greater customer centric services and customer relationship management.

• To increase efficiency and fairness in dealing with the general public, improving perception of the DMV as a valuable and helpful institution.

• To promote consumer education allowing the DMV to provide accessible education regarding offered products, services, and motor vehicle changing laws.

• To improving revenue collection efficiencies, improving public awareness of DMV services, reaching out to communities that are unplugged through education and marketing.

• To offer the experience of a One-Stop Shop to all customers in every DMV Field Service Office. • To deal with any and all DMV related informational and service generation capacities, such as general

Page 12: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 12 of 113

GOALS AND OBJECTIVES If applicable, this section should provide high level goals and objectives of the project. This can be incorporated

in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section. inquiries to specific legal issues.

• To shorten the time required to turn around background research that cannot be handled at the counter.

• To modernize communication systems that will enable DMV to generate specialized system-generated reports within a 24 hour period using VoIP, email, at a Kiosk station or through a DMV mobile app.

• To upgrade the front and back office GUI and UI interfaces meeting the new capabilities of service computing ensuring the customer and business facades are intuitive, simple, secure and self-educating.

• To generate real-time reporting data. • To explore big data applicability in order to grow and stimulate highly available educational and

marketing tools • To constantly update information improving DMV’s ability to influence and develop a smarter public

and a more resource driven DMV staff. • To remove the drudgery from the manual interface with customers including the limited data

accessibility of computer information during counter computer usage. • To streamline services increasing the number of available product choices and more independence

self-managing each individuals profile and account. • To promote public awareness improving public safety awareness using alternate technologies.

Public Safety • To ensure the sealing and securing of the driver license PII as it is the prime ID for Public Safety

checking of an individual’s profile, whereabouts and privileges. • To improve the banner of public safety by surveying and targeting specific communities, mitigating

burdens to the DMV, such as educating young teenage drivers, educating uninsured drivers, connecting unplugged communities, and lowering the high recidivism in DUI and substance abuse drivers

• To lessen the impact on the court system

• To improve the integration and management of court records and criminal profiles as well as constantly keeping tabs on the whereabouts of offenders.

• To abate the revolving door effect of DMV customers that fail to obtain the services in an expedient and timely manner, either through constant return visits or misinformation about document requirements as well as other eligibility data that causes Nevadans to be frustrated with the DMV process.

• To increase the seamlessness of the processing of the accuracy, sharing and updating of registered sexual offenders and driving offenders’ locations including the terms of probation and/or suspension,

• To secure the absolute secrecy of undercover work in the context of identity management. Business Enterprise

• To project the need to manage transactions based on a future exponential growth of the Nevada population over the next 15 years into the business architecture requirements.

Page 13: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 13 of 113

GOALS AND OBJECTIVES If applicable, this section should provide high level goals and objectives of the project. This can be incorporated

in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section.

• To work hand-in-hand with EITS to ensure the overall state system capacity interface can manage an ever growing DMV security and increased traffic load ensuring that all dependent and collaborative systems be well within the system tolerances of growth.

• To deliver the best Role (Product) based Profile Resourced (DMV Technicians) Calendar Appointment based Customer Friendly Portal to allow DMV to better manage its Customer handling and quality of service (QOS).

• To facilitate DMV to better manage and allocate its resources and information by developing rapid JIT coverage overlap; considering the outlier locations and the distance between DMV Service Offices.

• To centralize the expedient distribution of documents and license plates from a dual-centralized hub system removing the burden for offices to carry and manage inventories.

• To develop self-sufficiency by increasing the number of transactions and offered products available using alternative services.

• To deliver the best service model (SOA) that adds new dynamics to the inner DMV operations, the DMV interfaces with its partners

• To implement full failover with two (2) server farms securing a 24/7 failsafe replication that will meet all the operational transparency, business continuity and disaster recovery mandates, wherein DMV will no longer depend on a high-risk single site model.

• To avoid building another modern version of a monolithic mainframe by repeating the implementation of near-term legacy concepts when there is substantial and vastly improved mature technology readily available in the solution marketplace today.

• To vastly improve the automated sharing of information with all government agencies including non-governmental partners, reducing the creation of multiple versions of the same information in many different formats, leaving room for errors and ambiguity.

• To remove the manual process as much as possible from the collection of information to the manipulation of information by DMV staff; the effort is to consolidate the division of work using separate screens, apps and terminals to one terminal operational portal governed by roles and privileges.

• To offer all of the DMV services to be virtually shared throughout all physical locations as well as maximizing and optimizing mobile, kiosk and future technology driven portal accessibility with built in transparency, where the legislation permits.

• To streamline tax collection by enabling electronic tax filing, processing, auditing, collection and reimbursement of taxes.

• To improve compliance allowing the DMV to respond effectively for compliance and enforcement of motor vehicle laws using case management.

Zero Tolerant Security • To operate at the highest level of security stewardship, administering security measures that thwart the

most sophisticated threats and vulnerabilities to protect the most confidential if not secret data pertaining to the state of Nevada with state of the art countermeasures.

• To base the new system design on the most robust security framework by installing new concepts of decoupled architecture incorporating vault technology, following guidelines set out by but not limited

Page 14: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 14 of 113

GOALS AND OBJECTIVES If applicable, this section should provide high level goals and objectives of the project. This can be incorporated

in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section. to ISO, NIST, TOE, the Common Criteria and the State of Nevada regulations.

• To provide Common Criteria Quality Assurance utilizing Common Criteria (i). Evaluation Assurance Levels (EAL); the level of certification sought, using grades EAL1 through EAL7, (ii). Target of Evaluation (TOE); the system submitted for evaluation, and (iii). TOE Security Functions; set of all hardware, software, and firmware needed for the enforcement of the Zero Tolerant Security policy and (iv). Security Assurance Requirements (SARs); measures, compliance, and functionality.

• To provide Common Criteria Evaluations; (1). Protection Profiles (PP) and (2). Security Target (ST) requirements, and (3). Security Functional Requirements (SRFs), provided by product.

• To provide Zero Risk by destroying all information as soon as it is collected or by otherwise making information entirely inaccessible to anyone2.

• To provide Zero Risk by separating the process layer from the data layer with decoupled clients and interface staging areas.

• To provide Zero Risk by encapsulating all the system interactions under Division “A” Verified Protection as the predominating acceptable level of security using the Trusted Computer System Evaluation Criteria (TCSEC) semantics.

• To monitor and control all exploited internal and external vulnerabilities of basic and enhanced-basic brute force attacks through the exploitation of weak authentication and weak implementation of protocols allowing access to operating systems and networks.

• To monitor and control all attack potentials on internal and external vulnerabilities of high and beyond-high sniffing attacks through bypassing authentication on administrative traffic or through infiltration using default username/password or bypass authentication mechanism through other interfaces.

• To monitor and control all attack potentials visualized with threat agents and their attack potentials on internal and external vulnerabilities through non‐specified interfaces.

• To monitor and control all attack potentials on internal and external exploitation of unencrypted/weak/non‐standard crypto algorithms.

• To monitor and control all attack potentials on internal and external unauthorized access causing malicious intrusion, undetected system activity, resource exhaustion, user data disclosure and general Target of Evaluation (TOE) failures.

• To secure the most sensitive PII information in sealed vaults, possibly only accessible through escrow and trust management, access granted using avatars, gadgets and disseminated using barcodes.

Architecture

• To ensure that the architecture adopted, in whatever form or mode, is bound seamlessly by standards, policy and well-tried principles.

• To ensure that the architecture is not driven by the technology but by the capabilities required to perform the business function.

• To ensure that above all security is an embedded mandate for the enterprise architecture and that every measure to protect the data, the user and stakeholder is interwoven into the End-2-End principles of sustainable operations.

• To ensure that any alternative to the widely accepted and standardized MDM driven SOA must meet

Page 15: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 15 of 113

GOALS AND OBJECTIVES If applicable, this section should provide high level goals and objectives of the project. This can be incorporated

in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section. the highest standards equivalent to service orientation, that would equally allow the agency to optimize its business processes with application assets that return the fullest support, while avoiding redundancy, innumerable supply-chain systems, multiple CRM systems, as well as multiple and disparate disconnected application layers that fail to work effectively causing security bankruptcy.

• To ensure that the former legacy architecture is not replaced by a more contemporary legacy that is camouflaged with a modern wrapper.

• To remain open to advances in architecture without incurring unnecessary risk maintaining the philosophy and industry norm that service oriented architecture is the best-in-class and that there really are no viable alternatives other than COTS closed systems.

• That the agency will not consider any design or architecture that stifles ongoing advancements and evolution.

• That the agency will not consider any design or architecture or the components that come with it that has an expired shelf life.

• That the agency will consider Open System architecture as long as it is bound seamlessly by standards, policy and well-tried principles equivalent to MDM driven SOA.

Smart Technology • To remove all legacy concepts from the DMV systems

• To remove doing business as usual (BAU) • To realign the business process context and the behavior of data can

• To optimized the business process by utilizing new efficient technologies that are offered in MDM ecosystems in conjunction with shared service models.

• To shorten and streamline the data round trips to build DMV business processes • To use a lean approach incorporating end to end architecture

• To remove unnecessary builds and ETL processes caused by legacy technology • To inject first generation data into its ultimate destination in one transaction.

Sustainability • To leverage modernization IT capabilities across the entire DMV agency spectrum to facilitate

sustainability initiatives, where opportune. • To injecting smart ways to reduce carbon emissions that positively impacts the environment.

• To balance the usage of sustainability though appearing as small adjustments which are offset by major reorientation.

• To adopt IT sustainability practices that wholly serve business strategies and especially the environment in that sustainability is a top-down effort that can be horizontally worked into all verticals of the enterprise agency.

• To adopt IT sustainability practices such as going paperless, repurposing heat generated by data centers, optimizing servers and storage virtualization and leveraging cloud services

• To reduce waste, harness renewable energy and foster eco-friendly business practices.

• To include the following four modernization factors that distinguishes long-lived IT organizations to

Page 16: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 16 of 113

GOALS AND OBJECTIVES If applicable, this section should provide high level goals and objectives of the project. This can be incorporated

in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section. improve the environmental performance.

(i) Sensitivity and adaptability to the business environment (ii) Cohesion and sense of identity

(iii) Tolerance of diversity (decentralization) • To Enforce the cornerstones of sustainability into the modernization architectural paradigm3

Expected Change to DMV Operations

ACRONYMS/DEFINITIONS Agency/project specific acronyms/definitions to be added to the listing in the RFP

Acronym Definition

AAMVA American Administration of Motor Vehicle Administrators

ACA Affordable Care Act or ObamaCare

ACD AAMVA Code Dictionary

ACL Access Control List

AES Advanced Encryption Standard algorithm, a symmetric block cipher specification for the encryption of electronic data established by the U.S. National Institute of Standards

AICPA American Institute of Certified Public Accountants

Page 17: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 17 of 113

GOALS AND OBJECTIVES If applicable, this section should provide high level goals and objectives of the project. This can be incorporated

in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section. AMIE AAMVAnet Message Interchange Envelope

ANSI American National Standards Institute

API Application Program Interface

ASD Administrative Services Division

ASTM American Society for Testing and Materials

AVAYA An application used in the State of Nevada for phone and call center services.

BAU Business As Usual

B2B Business to Business

B2C Business to Customer

B2G Business to Government

BAC Blood Alcohol Content

BI Business Intelligence

BIOS Basic Input/Output System

BLOB Binary Large OBject

BN Billion

BOE Board of Examiners

BOE Board of Equalization

BPA Business Process Analyst

BPEL Business Process Execution Language

BPF Business Process Framework

BPO Business Process Outsourcing

BSD Berkeley Software Distribution (license)

CARRS Combined Automotive Revenue and Registration System; Fully integrated client server system written in Power Builder, VB.NET, ASP.NET, COBOL, DB2, and SQL.

CBC Cipher-Block Chaining

CC Cubic Centimeter

CC 2.1 Common Criteria for Information Technology Security. Evaluation

CDL Commercial Driver’s License

CDLIS Commercial Driver’s License Information System

CED Compliance Enforcement Division

Page 18: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 18 of 113

GOALS AND OBJECTIVES If applicable, this section should provide high level goals and objectives of the project. This can be incorporated

in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section. CERT Community Emergency Response Team

CFR Code of Federal Regulations

CIA Central Intelligence Agency

CICS Customer Information Control System

CIS Center for Internet Security

CLI Command Line Interface

CLP Commercial Learner’s Permit

CLASS M Motorcycle

CMS Call Management System

CMU SEI CMMI Carnegie Mellon Software Engineering Institute Capability Maturity Model Integration

COBOL Common Business Oriented Language

COTS Commercial Off the Shelf

CPA Certified Public Accountant

CPU Central Processing Unit

CR Cash Receipt

CREDENTIAL License, Decal, Cab Card, Registration etc.

CRM Customer Relationship Management

CSD Central Service Division

CSPRNG Cryptographically secure pseudorandom number generator

CSTIMS Commercial Skills Test Information Management System

CTI Computer telephony integration

CVIEW Commercial Vehicle Information Exchange Window

CVINA Complete Vehicle Identification Number Analysis

CVISN Commercial Vehicle Information and Network

DAC Driver’s Authorization Card

DASD Direct Access Storage Device

DAWN Data Warehouse of Nevada

DB Database

DETR Department of Employment Training and Rehabilitation

Page 19: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 19 of 113

GOALS AND OBJECTIVES If applicable, this section should provide high level goals and objectives of the project. This can be incorporated

in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section. DFB Delinquent Fine

DHHS Department of Health and Human Services

DHS Department of Homeland Security

DL Driver’s License

DLDV Driver License and Identification Card Data Verification DLL Dynamic-Link Library

DLN Driver’s License Number

DMV Department of Motor Vehicles

DMZ Perimeter network

DOD Department of Defense

DOT Department of Transportation

DPAPI Data Protection Application Programming Interface

DPL Data Protection Level

DPS Department of Public Safety

DR Disaster Recovery

DRl Driving on a restricted License

DSA Digital Signature Algorithm

DUAL_EC_DRBG Dual Elliptic Curve Deterministic Random Bit Generator

DUI Driving Under the Influence

EA Estimated Audit

EAL Evaluation Assurance Level

EAM Embedded Audit Module

E2E ARCHITECTURE End-to-End Architecture

ECDLP Elliptic curve discrete logarithm problem

ECDSA Elliptic Curve Digital Signature Algorithm offers a variant of the Digital Signature Algorithm

EDI Electronic Data Interchange

EDRS Electronic Dealer Report of Sale

eDS Electronic Lien and Titling System Vendor (eDealer Services)

EDW Enterprise Data Warehouse

Page 20: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 20 of 113

GOALS AND OBJECTIVES If applicable, this section should provide high level goals and objectives of the project. This can be incorporated

in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section. EFT Electronic Fund transfer EIDM Enterprise Identity Management

EITS Enterprise Information Technology Systems (formerly DoIT)

ELT Electronic Lien and Title

ELU Eluding Police Officer

EMR Electronic Medical Record

EPA Environmental Protection Agency

ERIC Electronic Registration Information Center is a program which holds a comprehensive database of voters across participating states with the goal of eliminating duplicate voter registration in multiple states.

ERP Enterprise Resource Planning

ESB Enterprise Service Bus

ESMT Extended Simple Mail Transfer

ESSIV Encrypted Salt-Sector Initialization Vector

ESX Elastic Sky X (hypervisor)

ETL Extract Transform Load

EVA Evading and Peace/Police Officer

EVVER Electronic Verification of Vital Events Records

FAC Waiting for MVIT to respond?

FBI Federal Bureau of Investigation

FED EX Federal Express

FEIN Federal Employer Identification Number

FIFO First In First Out

FIPS Federal Information Processing Standard

FIRST DATA Electronic Payment Vendor FLOSS Free/Libre/Open Source Software

FMCSA Federal Motor Carrier Safety Administration

FOSS Free Open Source Software

FR Federal Register

FRS (i) Failure-Resistant Systems

FRS (ii) Facial Recognition System

Page 21: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 21 of 113

GOALS AND OBJECTIVES If applicable, this section should provide high level goals and objectives of the project. This can be incorporated

in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section. FSD Field Services Division

FTP File Transfer Protocol

FURPS+ Functionality, Usability, Reliability, Performance, Supportability [+ = HP extended]

FURPS++ Functionality, Usability, Reliability, Performance, Supportability [+ = unified model extended]

FY Fiscal Year

GADGETS A gadget is a small tool or application such as a virtual machine that has a particular niche function sometimes referred to as gizmos.

GAO General Accountability Office

GL General Ledger

GNU GNU's Not Unix (non-UNIX OS) GPL General Public License

GPS Global Positioning System

GST Government Services Tax

GUI Graphical User Interface

GVWR Gross Vehicle Weight Rating

GYR Green-Yellow-Red

HAVA Help America Vote Act

HAZMAT Hazardous Material

HDD Heavy Duty Diesel

HIGH DESERT Scanning Vendor

HIPAA Health Insurance Portability and Accountability Act

HR Human Resources

HTML Hyper Text Mark Up Language

HTTPS Hypertext Transfer Protocol Secure

I/M Inspection and Maintenance Advisory Committee

I/O Input/Output

IaaS Infrastructure as a Service

IBM Z SYSTEMS Computing transaction engine hardware for new mobile apps infrastructure ICS Industrial Control Systems

ID Identification

Page 22: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 22 of 113

GOALS AND OBJECTIVES If applicable, this section should provide high level goals and objectives of the project. This can be incorporated

in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section. IDE Integrated Development Environment

IEC International Electrotechnical Commission

IEEE Institute of Electrical and Electronics Engineers

IFS Integrated Financial System

IFTA International Fuel Tax Agreement

IICMVA Insurance Industry Committee on Motor Vehicle Administration The liaison between the insurance industry and Motor Vehicle Departments in the US and Canada.

IP Internet Protocol

IRP International Registration Plan

IRS Internal Revenue Service

IRW Image Retrieval Workstation

ISAE International Standards for Assurance Engagements

iSight iSight Case Management System which is an internet based tool that provides case management tracking of investigations.

ISO Information Security Officer

ISO International Organization for Standardization

ISO 15048 General Concepts & Principles of IT Security Evaluation

ISO 27001 Information Security Management

ISO 27002 Security Framework (formerly ISO 17799)

ISO 2700X Security Standard Master for ISO 27001 & ISO 27002

ISSA Information Systems Security Association Communication Requirements

IT Information Technology

ITI Intellectual Technology Inc.

ITP Information Technology Programmer

ITPI IT Process Institute

IVP Insurance Verification Program [now referred to as Nevada LIVE]

JDK Java Development Kit

JEE Java Platform Enterprise Edition

J2EE Java 2 Platform, Enterprise Edition

J2SE Java 2 Platform, Standard Edition

Page 23: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 23 of 113

GOALS AND OBJECTIVES If applicable, this section should provide high level goals and objectives of the project. This can be incorporated

in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section. JIT Just-In-Time

JLINK Justice Link

JV Journal Voucher

KPI Key Performance Measure KPO Knowledge Process Outsourcing

KVM Keyboard, Video, Mouse

LAN Local Area Network

L1 (MorphoTrust) Driver License and Identification Card Production Vendor

LCB Legislative Counsel Bureau

LCV Longer Combination Vehicle LGPL Lesser General Public License

LIFO Last In First Out

LPAR Logical Partition LPO Legal Process Outsourcing

MC Motor Carrier

MC45 Motor Carrier Refund Form for Gas/Diesel Tax

MCD Motor Carrier Division MCSIA Motor Carrier Safety Improvement Act

MCTS Motor Carrier Tax System

MDM Master Data Management MDM ECOSYSTEM The circulation of Master Data by core capabilities and technologies that provide the

glue between upstream and downstream systems. MDS Microsoft Deployment Services

MIT Massachusetts Institute of Technology

MOODLE Modular Object Oriented Dynamic Learning Environment

MOSA Modular Open Systems Approach

MPC Monthly Project Charges

MPG Miles Per Gallon

MPM Master Project Manager

MS Microsoft

Page 24: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 24 of 113

GOALS AND OBJECTIVES If applicable, this section should provide high level goals and objectives of the project. This can be incorporated

in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section. MSA Master Services Agreement

MS .NET Microsoft Dot Net Framework

MSO Multi-System Operator

MS&P Management Services and Programs Division

MSRP Manufacturer’s Suggested Retail Price

MV Motor Vehicle

MVA Motor Vehicle Agencies

MVR Motor Vehicle Record

MVIP Motor Vehicles Industry Portal

MVIT Motor Vehicle Information Technology

MyDMV DMV Portal Account

NAC Nevada Administrative Code

NACD National Association of Corporate Directors

NADA National Automotive Dealers Association

NAIC Nevada Citation/Accident Tracking System

NAICS North American Industry Classification System

NAPHSIS National Association for Public Health Statistics and Information Systems

NCATS Nevada Citation and Accident Tracking System NCCIC National Cybersecurity and Communications Integration Center

NCDL Non Commercial Driver’s License

NCIC National Crime Information Center

NCJIS Nevada Criminal Justice Information System

NCORS Nevada Commercial Online Registration System

NCS Network Control Software

NDOT Nevada Department of Transportation

NEATS Nevada Employee Action and Timekeeping System

NEBS Nevada Executive Budget System

NEIM National Information Exchange Model

NFE Non-Functional Exceptions

NHTSA National Highway Traffic Safety Administration

Page 25: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 25 of 113

GOALS AND OBJECTIVES If applicable, this section should provide high level goals and objectives of the project. This can be incorporated

in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section. NIST National Institute of Standards and Technology

NLA An indicator which represents a SR22 requirement due to a vehicle registration reinstatement.

NLB

A withdraw action which initiates a 30 day driver’s license suspension. This is a penalty for insurance offenders who have reached or exceeded their third offence of no insurance within a 5 year period. The withdraw code is added to the DL when processing the vehicle registration reinstatement.

NMVITS National Motor Vehicle Title Information System

NOMADS Nevada Operations of Multi–Automated Data Systems

NORRS Nevada Out- of-State Registration Reporting System

NRS Nevada Revised Statutes

NSA National Security Agency

NSF Non-Sufficient Funds (Insufficient)

NSOR National Sex Offender Registry

NV Nevada

Nevada LIVE Nevada Liability Insurance Validated Electronically

OAG Office of the Attorney General

OBD On Board Diagnostics

OBD-II On Board Diagnostic System. Emission inspection that utilizes the vehicle’s on board computer to test the vehicle’s emission system.

OBL Occupational and Business Licensing

OCR Optical Character Recognition

ODS Operational Data Store

OHV Off Highway Vehicle

OIS Office of Information Security

OLAP Online Analytical Processing OSI Open Source Initiative

OPSEC Temporary Placard Vendor

OPTEC Vision Test System Vendor

ORGANIZATIONAL SILOS

Silos can be departmental separation, or executive separation from operational as well as geographical separation where horizontal information and management is not equally shared or distributed.

OS Operating System

OSS Open Source Software

Page 26: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 26 of 113

GOALS AND OBJECTIVES If applicable, this section should provide high level goals and objectives of the project. This can be incorporated

in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section. P&P Policy and Procedure

PaaS Platform as a Service

PARADOX Database tracking system in MCD to track receipt, balance, and aging of negotiable items and payments. A non-supported database.

PAYPOINT Electronic Payments via First Data

PDF Portable Document Format

PDPS Problem Driver Point System

PII Personally Identifiable Information

PIO Public Information Officer

PM Program Manager

PMI Project Management Industry

PMO Project Management Office

PMP Project Management Professional

PMT Project Management Team

POA Power of Attorney

POC Proof of Concept

POD Print On Demand

POLK Vin Decoding Company with CVINA product offering.

PP Protection Profile

PPS Productivity Platform Suite

PRISM Performance and Registration Information Systems Management

PSR Project Service Request

PTO Power Take Off

PV Payment Voucher

PVA Point Violation

Q&A Question and Answer

QA Quality Assurance

QAS Quality Address System

QLESS Customer Queuing System Vendor

QOS Quality Of Service

Page 27: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 27 of 113

GOALS AND OBJECTIVES If applicable, this section should provide high level goals and objectives of the project. This can be incorporated

in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section. RA Reference Architecture

RACF Resource Access Control Facility

RDBMS Relational Database Management System

RDZ Rational Developer for System z

RFID Radio-Frequency Identification

RFP Request for Proposal

RHA Reckless Driving /Hit and Run

RISS Regional Information Sharing System

RMF Risk Management Framework

RMIN Rocky Mountain Information Network

RMM Removable Media Manager

ROI Return on Investment

ROOSTER

Report Out of States Test Results – AAMVA development system that supports rule § 383.79 of the new CLP regulation. The regulation provides that a person who holds a CLP will be able to take the CDL skills test outside of his/her state of domicile. The rule also requires that states be able to exchange electronically test results in a safe and secure manner by July 08, 2015.

RPC Remote Procedure Call

RSA Rivest-Shamir-Adleman algorithm, a cryptosystem for public-key encryption

S2S State to State Verification Service

SaaS Software as a Service

SAFER Safety and Fitness Electronic Records

SAM State Administrative Manual (Nevada)

SANS INSTITUTE System Administration, Networking, and Security Institute a Private U.S. company that specializes in information security and cybersecurity training

SARS Security Assurance Requirements

SAS-70 Statement on Auditing Standards (SAS) No. 70

SAVE Systematic Alien Verification for Entitlements

SDA Suspension based on Security deposit

SDLC System or Software Driven Lifecycle

SECURITY ECOSYSTEM

A security ecosystem is a model of infinite possibilities (similar to the UNIX shell) that functions similarly to the human immunity system. The ecosystem is highly sensitive to the ever evolving synthesis and distribution of incalculable gradations of continual threats and vulnerabilities. The ecosystem is supported by strategic and

Page 28: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 28 of 113

GOALS AND OBJECTIVES If applicable, this section should provide high level goals and objectives of the project. This can be incorporated

in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section. nimble executable countermeasures that interweave systemically through a complex array of interdependent assets. The security components working together thus enable informational systems to work with the highest levels of seamless indemnification of human intervention and interaction producing a cohesively secure and holistic system.

SEI CCMI Software Engineering Institute Capability Maturity Model Integration

SEP Systems Engineering Plan

SFR Security Functional Requirements

SFTP Secure File Transfer Protocol

SHA Secure Hash Algorithm designed by the National Security Agency (NSA) to be part of the Digital Signature

SIEM Security Information and Event Management

SL Service Level

SLA Service Level Agreement

SLO Service Level Objective

SM System Modernization

SME Subject Matter Expert SMS Storage Management System

SMTIR System Modernization Technology Investment Request

SOA Service Oriented Architecture

SOC Service Organization Control

SOC-1 Policy Packets on Reports on Controls at a Service Organization and SSAE 16

SOC-2 Policy Packets on AICPA

SOC-3 Reports and Trust Service Principles

SOR State of Record

SOW Statement of Work

SOX Sarbanes-Oxley Act Sections 302 & 404

SQL Structure Query Language

SR22 Certificate of Financial Responsibility

SRI Stanford Research Institute

SSA Social Security Administration

SSAE Statement of Standards for Attestation Engagement

Page 29: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 29 of 113

GOALS AND OBJECTIVES If applicable, this section should provide high level goals and objectives of the project. This can be incorporated

in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section. SSN Social Security Number

SSO Single Sign-on

SSOLV Social Security On Line Verification

SSRS Single State Registration System

ST Security Target

STS Solutions Thru Software – Knowledge test vendor for drivers licenses

STOVEPIPE (Organization)

A stovepipe organization has a structure which largely or entirely restricts the flow of information within the organization to up-down through lines of control, inhibiting or preventing cross-organizational communication.

TCP/IP Transmission Control Protocol & Internet Protocol

TCSEC Trusted Computer System Evaluation Criteria

TIR Technology Investment Request

TOE Target of Evaluation

TS Tax System (Xerox)

TSA Transportation Security Administration

TXI Tax Industry

UAT User Acceptance Testing

UC Under Cover

UI User Interface

UID Unique Identification

UNBUNDLING

A neologism of leanness or etymology to describe how the ubiquity of mobile devices, Internet connectivity, consumer web technologies, social media and information access today is affecting older institutions as in government agencies by breaking down the stove pipes and narrow unwieldy packages once offered, providing particular parts of them at a scale and cost unmatchable by the old order of doing business.

UNI Unified Network Interface

UNIX Uniplexed Information and Computing System - A multi-user operating system.

UNIX/SS7 A multi-user operation system signaling system 7. UPS Uninterruptible Power Supply

URI Uniform Resource Identifier

URL Uniform Resource Locator

U.S. United States

Page 30: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 30 of 113

GOALS AND OBJECTIVES If applicable, this section should provide high level goals and objectives of the project. This can be incorporated

in the Project Overview Section. More specific goals and objectives should be included in the Scope of Work Section. USA Unsatisfied Judgment

USCIS United States Citizenship and Immigration Services

US GAAP United States Generally Accepted Accounting Practices

USPS United States Postal Service

USPV United States Passport Verification

VA Veterans Administration

VID Vehicle Information Database

VIN Vehicle Identification Number

VLAN Virtual Local Area Network

VLS Verification of Lawful Status

VM Virtual Machine

VMM Virtual Machine Monitor or Hypervisor

VoIP Voice over Internet Protocol

VPN Virtual Private Network

VTS Vision Test System

Virtual In computing, refers to the act of creating a virtual (rather than actual) version of something, including but not limited to a virtual computer hardware platform, operating system (OS), storage device, or computer network resources.

VISTA FINANCIAL An interface for transaction payment and distribution

W6A Commercial Driver’s License infraction

WAN Wide Area Network

WEB World Wide Web

WIFI Wireless Technology

WSDL Web Service Description Language

XML Extensible Markup Language

XNIS Cross Nevada Information System – A system developed by EITS to facilitate access to DMV data by other State Agencies.

ACRONYMS – TO BE DELETED List those acronyms that can be deleted from the listing in the RFP

Acronym Acronym Acronym Acronym Acronym

Page 31: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 31 of 113

ACRONYMS – TO BE DELETED List those acronyms that can be deleted from the listing in the RFP

BACKGROUND - PROJECT Describe the history and reasons behind the project.

In 1999, DMV rolled out the current client-server application to replace the legacy Green screen application that ran on Honeywell Bull system. The current client-server application supports statewide motor vehicles business functions including but not limited to Vehicle Registration, Titling, Commercial and non-Commercial Driver Licensing, Occupational Business Licensing, Insurance Verification, etc. The current client-server application is composed of desktop PowerBuilder application that provides intuitive Graphical User Interface, ASP.NET web applications, and COBOL/CICS/DB2 application that runs on System Z.

Though the current application integrates several core business functions, DMV continues to rely on few vendor provided legacy applications to provide services. The number of manual processes and procedures that are employed to address limitations in the current system is on the rise. The current architecture inhibits our ability to be nimble, proactive and agile. Consequently, the time to implement newer projects mandated by legislature and the Federal Government has been on the rise. The current system limits DMV’s ability to adapt and offer modern services that citizens expect. As a result, the backlog of enhancements and fixes requested has been steadily climbing. The amount of backlog is currently estimated to be 7 years’ worth.

BACKGROUND - AGENCY Describe the agency’s organization and functional units; office locations;

staffing, etc., including relationship to current project. The DMV Agency [Placeholder]

Page 32: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 32 of 113

BACKGROUND - AGENCY Describe the agency’s organization and functional units; office locations;

staffing, etc., including relationship to current project.

The Department of Motor Vehicles (DMV) is a multi-divisional organization which provides vehicle and driving industry products and services to Nevada citizens, state agencies, and internal customers. DMV business is transacted through 18 office locations in Northern and Southern Nevada. The DMV includes the Director’s office and seven divisions. The Director's Office (which includes Public Information and Hearings Offices) establishes policy for the department and directs and controls the operations of the agency. The Director's Office handles all media inquiries through the Public Information Officers. Additionally, department policies and procedures, information security and the personnel and training units fall under the responsibility of this office.

The Public Information Officer interacts directly with the public and act as a liaison with other Public Information Officers and officials from federal, state, local and non-governmental organizations. The PIO coordinates and scripts press releases and public service announcements to promote alternative services offered by the Department and create informational flyers, posters, brochures and videos as requested by the Director or Deputy Director. The PIO also performs as the public relations officer; providing marketing communication and public program strategy oversight; manages the public relations and information program for the Department on a statewide basis; writes media releases, newsletters, and informational brochures; produces audiovisual presentations and photography duties.

The Hearings Office provides due process hearings to any person aggrieved by a decision of the Department. Generally, these hearings concern the suspension, revocation, or cancellation of a privilege license issued by the Department, such as a driver's license or a license to conduct business involving

Page 33: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 33 of 113

BACKGROUND - AGENCY Describe the agency’s organization and functional units; office locations;

staffing, etc., including relationship to current project. motor vehicles. The decisions of the administrative law judges assigned to the Office may impact the lives and property of thousands of Nevadans. For this reason, the Office strives to conduct all hearings in a timely, fair, and impartial manner and in accordance with the provisions in the Nevada Administrative Procedures Act, Chapter 233B. The Office is supported primarily from Highway Fund revenues.

Under the general direction of the Director, Deputy Director and Chief Information Security Officer, the Information Security Officer is responsible for the development and delivery of a comprehensive information security and privacy program for the department of Motor Vehicles. The scope of the program concentrates on state wide oversight of physical and cyber security of all DMV assets, including heavily integrated affiliations with other state agencies, federal agencies, and private sector entities.

The purpose of this program includes but is not limited to: the protection of all IT and human assets while ensuring that all information and data created, generated acquired, maintained and disseminated by the department is safeguarded and used for its intended purpose; to protect the department’s information, personnel and infrastructure from all forms of internal and external threats; assure the department complies with statutory and regulatory requirements regarding information access, security, privacy and dissemination; and to provide strategic and tactical input, design and oversight for the next generation of the agencies product and service infrastructure.

Each division within the Department administers several programs. The divisions and examples of administered programs are as follows:

Central Services Division (CSD), Field Services Division (FSD), Motor Carrier Division (MCD), Management Services and Programs Division (MS&P), Administrative Services Division (ASD), Compliance Enforcement Division (CED) and Motor Vehicle Information Technology (MVIT). The Central Services and Records Division (CSD) provide alternative methods for Nevada motor vehicle customers regarding drivers' licenses, registrations, titles, and license plates. This division is also responsible for processing titles, ensuring data integrity and applying driver license sanctions.

The License Plate Factory is also operated by the Central Services and Records Division. Also known as the "Tag Plant," the License Plate Factory is charged with designing, manufacturing, and distributing Nevada's license plates to DMV offices and State Assessors Offices for issuance to vehicle owners and operators in Nevada.

The Insurance Verification Program, known as Nevada LIVE (Nevada Liability Insurance Validated Electronically), verifies that registered owners of motor vehicles registered in Nevada maintain liability insurance. Revenue is generated from reinstatement fees and fines after suspensions for no insurance

The Field Services Division (FSD) is responsible for direct customer service operations for the driver licensing and vehicle registration functions. Field Services assures that only safe and knowledgeable drivers receive the privilege to drive on the highways. It also registers and titles vehicles, and collects appropriate fees and taxes imposed upon the owners and operators of vehicles. The Motor Carrier Division (MCD) is responsible for ensuring compliance with Nevada laws applicable to its Motor Carrier Customers. This includes administration of special fuel and motor fuel supplier programs to fairly collect and distribute the total fuel tax revenue owed to Nevada; licensing all commercial vehicles over 26,000 pounds; licensing vehicles with interstate operations under the International Registration Plan (IRP) and International Fuel Tax agreement (IFTA); revenue and bad debt collections; and conducting audits of motor carriers and fuel suppliers to ensure customer education and compliance with Nevada laws and regulations, the International Registration Plan (IRP), and the International Fuel Tax Agreement (IFTA).

Page 34: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 34 of 113

BACKGROUND - AGENCY Describe the agency’s organization and functional units; office locations;

staffing, etc., including relationship to current project.

The Management Services and Programs Division (MS&P) is a resource to help achieve the department's strategic plan goals and is responsible for developing regulations; drafting legislation; preparing fiscal notes, surveys, forms, and desk reference manuals; developing requests for proposals; and managing projects related to vehicle, driver, occupational, and business programs. This division develops policies and procedures for all Department of Motor Vehicles (DMV) divisions to ensure consistent and uniform program delivery. Division responsibilities also include support for the other divisions in the areas of strategic planning, research, coordination of regulation and statutory changes, and legislative interaction

The Administrative Services Division (ASD) is charged with providing professional, timely, and accurate support services to the Director, various divisions of the department, and other associated agencies. Support services include fiscal accounting, budgeting, travel arrangements, payroll, warehousing, inventory control, mail services, purchasing services, contract management, facilities management, revenue collection, revenue distribution, and bad debt service. Through its centralized functions, it provides services to all divisions within the department. With the centralized services, the department is able to ensure consistency, accuracy, and compliance with laws and regulations for all divisions in these service areas.

The Compliance Enforcement Division (CED) is the regulatory arm of the Department of Motor Vehicles. Regulation of the auto industry provides consumer protection through the licensing and regulation of businesses related to the manufacture, transport, sale, and disposal of vehicles. The purpose of the fraud investigation section is to investigate and resolve fraudulent activity. The Division also investigates all complex and criminal complaints filed against licensees. Staff conducts audits, monitors, inspects, and provides investigative services on the internal and external entities related to the DMV core programs

The purpose of the Emissions Control Program is to ensure that vehicles in Clark and Washoe Counties comply with Nevada's laws and regulations regarding emission standards. The division carries out its role by licensing and regulating emissions stations and inspectors as well as provides training and certification of applicants seeking employment as Emission Inspectors. Staff conducts audits and inspections at licensed emission stations; investigates potential program evaders and applies appropriate sanctions against program violators. The division cooperates with the various planning agencies involved in the Air Quality Program to evaluate air quality standards. The division is also a core member of the Inspection and Maintenance (I/M) Advisory Committee

The Motor Vehicle Information Technology Division (MVIT) provides data processing support for the Department of Motor Vehicles. MVIT is responsible for the development of new programs, enhancements to existing programs and maintains application systems and the necessary infrastructure for systems data, as well as provides technical and operating support.

Project Organization - Team

Page 35: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 35 of 113

BACKGROUND - AGENCY Describe the agency’s organization and functional units; office locations;

staffing, etc., including relationship to current project.

Projected System Modernization Organization

Project Timetable

Gant Chart Dead Link?

Project Roll-out

The DMV recommends an Agile role out. All of the service layers are dependent on the maturity of the implementation of the Financial GL Hub.

Page 36: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 36 of 113

BACKGROUND - AGENCY Describe the agency’s organization and functional units; office locations;

staffing, etc., including relationship to current project.

Suggested Roll-Out by Iterative Time-box

CONCURRENT IMPACTS / PROJECTS

Describe any concurrent projects that may have an impact on the project identified in the RFP Future legislative bills introduced in any Legislative Session and Federal mandates could impact business requirements with this project.

CURRENT COMPUTING ENVIRONMENT Describe the agency’s current computing environment

Current Computing Environment

The current computing environment is composed of PowerBuilder (thick client) application that power the DMV technician’s desktop, and ASP.NET web applications that both technicians and citizens of the State use. The client .NET and PowerBuilder applications invoke COBOL RPCs that run on IBM System Z. DB2 database on System Z serves as the core system of records. SQL Server database is also used to hold discrete application data. SQL Anywhere database is used as the local database that PowerBuilder application connects to display static reference data such as drop downs.

The following diagram is a high-level overview of the current technology platform.

Page 37: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 37 of 113

CURRENT COMPUTING ENVIRONMENT Describe the agency’s current computing environment

The following section provides an overview of DMV’s current computing environment and applications. Application Overview

DMV engages services from its Motor Vehicle Information Technology (MVIT) unit to support core program competencies. MVIT works closely with DMV business end-users, management and external customers to ensure that data is properly collected, processed, stored and reported. Day-to-day MVIT services include code maintenance, database and server administration, LAN support, local phone and Call Center support, desktop support, computing operations and project management. Several of DMV’s automated applications utilize the State's Enterprise Information and Technology Services (EITS) IBM mainframe and/or wide area communications network for statewide communications and volume processing. CARRS – The Department of Motor Vehicles (DMV) application (CARRS) is DMV’s core integrated business application for conducting vehicle registration and driver license transactions. CARRS is a fully integrated client server system written in Power Builder, VB.NET, ASP.NET, COBOL, CICS, DB2, JCL, TSO/ISPF and SQL. The DMV application has over 800 internal users, many external customers and interfaces with local, State and Federal agencies. Nevada DMV received federal grant funding to integrate and implement VLS (Verification of Lawful Status) and USPVS (US Passport Verification System) within the DMV CARRS application. The DMV will be working on integrating and implementing VLS and USPVS systems with the CARRS application. All of the required functionality will be added to the DMV application in accordance with the VLS and USPVS documentation.

Page 38: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 38 of 113

CURRENT COMPUTING ENVIRONMENT Describe the agency’s current computing environment

Data is stored in DB2 tables on the Mainframe. Access to the data is done through COBOL RPCs using SQL. There is also a good amount of business logic stored in COBOL RPCs to be created and/or modified. CARRS interfaces with AAMVA Net using UNI or Web Services to verify immigration documents and track the status of all open cases. CARRS was developed with vendor help and has been functioning since September 1999. CARRS is currently enhanced and maintained by MVIT. The functionality in CARRS includes:

• Vehicle registration and all its related components; • Driver License and it related components; • Reporting on stored data; • Cashiering and accounting; • General Ledger Account maintenance; • Debt Collections; • Hearings, Audit and investigations; • Call center interface • Insurance data verification • Interface to AAMVA and other vendor applications necessary to complete DMV transactions.

As part of this RFP, the vendor will replace and modernize the CARRS application to improve internal processing and customer demands. NCORS (Nevada Commercial Online Registration System) – is a web based system that is used by Motor Carrier division personnel to register commercial vehicles that are not processed through CARRS. This system allows installment payments and uses the IRP clearing house. NCORS functionality includes:

• Commercial Fleet maintenance; • Fleet registrations; • Cashiering and accounting; • General Ledger Account maintenance; • Hearings, Audit and investigations;

NCORS is an internally developed application and was implemented in 2009. As part of this RFP, the vendor will replace and modernize the functionality supported by the current NCORS applications to improve internal processing and customer demands. IFTA (International Fuel Tax Association) – is a vendor supplied and maintained system that is used by Motor Carrier division personnel to collect and distribute Carrier Fuel taxes. This system uses IFTA clearing house. IFTA functionality includes:

• Submission of Carrier tax return; • Collection of Fuel taxes; • Cashiering and accounting; • General Ledger Account maintenance; • Hearings, Audit and investigations;

As part of this RFP, the vendor will replace and modernize the functionality supported by the current IFTA

Page 39: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 39 of 113

CURRENT COMPUTING ENVIRONMENT Describe the agency’s current computing environment

applications to improve internal processing and customer demands. Motor Fuel Supplier Tax application – is a web based system that is used by Motor Carrier division personnel to collect Supplier Fuel tax. This system functionality includes:

• Submission of Supplier tax return; • Collection of Fuel taxes; • Cashiering and accounting; • General Ledger Account maintenance; • Hearings, Audit and investigations;

Motor Fuel Supplier Tax application is an internally developed application and was implemented in 2005. As part of this RFP, the vendor will replace and modernize the functionality supported by the current Motor Fuel Supplier Tax application to improve internal processing and customer demands. Web transactions Currently DMV has a number of transactions available on its website www.DMVNV.com. MVIT continually adds DMV transactions for the ease and convenience of Nevada citizens. MyDMV Portal MyDMV Portal was developed internally by MVIT staff and provides central access to customer data by allowing Nevada citizens to log into one place to access their records. A number of Web transactions are available to customers through the portal. In addition, this is the only online option where customers are allowed to complete their address change without having to visit a DMV office. As of November 2014, there are over 350,000 MyDMV portal accounts with over 630,000 transactions. Current Computing Infrastructure DMV’s existing automated applications and components drive the Department’s current computing infrastructure. For several of the core legacy applications the Department uses a combination of IBM mainframe technology including COBOL, DB2 and CICS programs in the backend and Power Builder, VB.net & ASP.net in the front end with a home grown INTERSPACE middle layer. DMV uses Microsoft servers running 2008/12. Microsoft Windows and MS Office suite products, including MS Internet Explorer. Current Environment and tools (Back-end) Currently the DMV application is two-tiered. Over 90% of the business logic and data reside on IBM’s System Z environment. The software component on the Mainframe that serves as the transaction server is called CICS. Connections to CICS are established through HTTP over TCPIP. Access to Transaction is controlled through RACF (Resource Access Control Facility) software on the Mainframe. Controlled access to transactions and application features are enabled through DMV written software component named Identity and Access Management software. Business users invoke RPC (Remote Procedure Call) programs that are managed by CICS. COBOL programs encapsulate most of the business logic and accesses DB2 on System Z to retrieve, update and save application data. In addition to online

Page 40: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 40 of 113

CURRENT COMPUTING ENVIRONMENT Describe the agency’s current computing environment

transactions, a number of batch program are run through Batch Scheduler. The following is a high-level overview of back-end technical infrastructure that provides runtime services. Identity and Access Manager Nevada DMV built this software component that provides crucial services to authenticate and enable com- munication between Applications that run on Windows and System Z environments. Identity and Access Manager uses IBM’s RACF to manage users, authenticate, and control access to System Z resources. In addition, access to specific business transactions are controlled through this software. CICS Transaction Server IBM’s CICS hosts online application programs. CICS enables COBOL programs as end point services that process requests from client applications that run on Windows environment. DB2 DB2 database on System Z serves as the central repository for core system of records. DB2 Connect DB2 Connect provides ODBC, ADO.NET, JDBC drivers to access DB2 databases from applications. Used for ETL and ad-hoc report generation. ZEKE ZEKE batch scheduler enables us to schedule, monitor and manage our batch schedule. Output Manager Output Manager enables to archive job logs, and batch output for specified period of time. It also provides ability to view, and print output. Removable Media Manager (RMM) RMM enables us view and manage data residing on removable media (tapes). BPF Sound Software Sound Software enables to generate and print barcodes. Informatica Identity Systems Informatica Identity Systems Name 3 software enables us to do fuzzy searches, match business and individual names to obtain a score that indicates how close they match. UNI (AAMVA) Software AAMVA/UNI software enables DMV to communicate and share information with other State and Federal entities. Secure FTP Server Nevada DMV built this software to handle data interchange between DMV and several Insurance carriers. The software provides application specific requirements to automate processing of Insurance carrier’s books of business. Real-time multi-threaded Insurance inquiry processor Nevada DMV built this framework to randomly inquire liability insurance real time through insurance carrier provided web service. The framework provided the ability to single-thread inquiries to each insurance company and spawned as many child tasks that are allowed to concurrently run. The framework also allowed

Page 41: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 41 of 113

CURRENT COMPUTING ENVIRONMENT Describe the agency’s current computing environment

users to view last few insurance calls from the trace buffer, start, stop, and pause all or specific tasks.

The following is a high-level overview of back-end Application Development and System administration tools. Debug tool - Enables ability step through application program. Fault Analyzer - Helps with analysis unchecked exceptions by formatting application and system dumps. File Manager – Enables programmers to edit, create, view data residing on supported file systems. It also packs a number of productivity tools for System Z application development. RDZ – IDE for System Z application development. LifeCycle Manager – SCM tool to manage versions and build DB2 Admin tool – Database administration tool DB2 Object Compare – Tool that allowed DBAs to implement and promote database changes to various environments. DB2 Query Monitor – Tool to capture and analyze performance metrics of application SQLs. Omegamon for DB2 – Tool for monitor real-time and snapshot Database performance metrics Omegamon for CICS – Tool to monitor real-time and snapshot Transaction server performance metrics RMF – Tool that provides insight into overall System Z performance metrics SMS – IBM’s Storage Management software that enables DMV to migrate data to cheaper storage media and recall them to active disk when needed seamlessly. The software also archives, backs up and delete aged data based on rules. Infrastructure related information:

1) User Desktop – Windows 7 2) Server – Windows 2008R2 & 2012 3) SQL Server – 2008R2 4) Web Server – Windows 2008R2 5) Network Interface – RJ45 - 1Giga bit to Desktops 6) VMWare Ver. 5 7) SAN Storage replicated North & South.

A listing of software, hardware, and development products currently in use is found in Table I, Current Computing Infrastructure, below.

Table I - Current Computing Infrastructure

Page 42: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 42 of 113

CURRENT COMPUTING ENVIRONMENT Describe the agency’s current computing environment

Database Products

VSAM, Flat Files, DB2V10, SQL Server 2008R2, Paradox, Access DB, SQL Anywhere (Sybase)

Computing Platform IBM Mainframe, MS Windows Server 20xx, VMWare Ver. 5

Network TCP/IP, WAN, Cisco, F5

Storage

Mainframe DASD, Storage Area Network, Tape Cartridges, Virtual Tapes (VTS)

Application Infrastructure

Microsoft Visual Studio 2008/2010, Sybase Power Builder V12, Interspace, IBM RDz, Humming Bird, Crystal Reports Ver. /10, QAS Batch Software, Dameware, Acrobat Write Pro 10, Sybase SQL Anywhere, PDF4Net, PDF4View, MS SQL Server 2008 R2, MS Team Foundation Server, Microsoft Internet Information Services, Adobe Acrobat X PRO, Microsoft SharePoint 2010, IBM CICS Transaction Server, IBM DB2, IBM DB2 Connect, ZEKE, IBM Output Manager, IBM Removable Media Manager, Informatica Identity Systems, BPF Sound Software, UNI (AAMVA), Identity and Access Manager, Secure FTP polling processor, TAL Barcode Software, Debug tool, Fault Analyzer, File Manager, RDZ, LifeCycle Manager, DB2 Admin tool, DB2 Object Compare, DB2 Query Monitor, Omegamon for DB2, Omegamon for CICS, RMF, SMS, F5 (NLB), SQL Server Cluster

Typical Desktop

Dell Optiplex 7010 (OptiPlex 7010, 8GB Ram, 1GB AMD video card, 500GB SATA HHD, I7 3.4GHz processor, Single 22” monitor)

Front Counter Peripherals Barcode Scanner, IPad (Credit Card Scanner), Document Scanner (Canon M160), POD Printer, Dell (Laser) Printer – All are USB ports except POD Printers.

Power User’s Desktop

Dell Precision 1700 (Precision 1700, 8GB Ram, 1GB NVIDIA video card, 500GB SATA HHD, I7 3.60GHz processor, Dual 22” monitors)

Email Communications MS Exchange Server 2010

Page 43: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 43 of 113

CURRENT COMPUTING ENVIRONMENT Describe the agency’s current computing environment

Productivity Suite Microsoft Office

Typical Workstation Printer Dell Laser 5460

High Volume/High Speed Printers Oce VarioPrint 110 Laser Printers, Printronix P700 Series Line Matrix, High Volume POD Printers, Batch Decal Printers

Network Infrastructure Cisco Switching / Routing

Interactive Voice Response Unit Avaya Equipment

Call Management / Call Center Phone Switching Avaya CTI / CMS Application

Document Imaging Kodak, WebXtender, ASD Document Imaging, Colfax

Anti-Virus Software Symantec Virtualization Environment

DMV utilizes server virtualization technology to consolidate resources, maximize technology investment, and improve the speed and efficiency in which server, storage, and application resources are deployed and managed. Currently, DMV hosts non-mainframe applications on Microsoft Windows Server operating systems. For the Microsoft Windows Server environment, VMWare ESX Server hypervisor technology is used to partition physical servers into multiple virtual machines each with its own reconfigurable subset of machine resources to support application needs. While storage virtualization technology may be considered in the future it is not currently used; however, DMV is actively researching client/desktop virtualization technologies for future use. XML, Web Services and SOA

For various DMV application enhancements, DMV has or is deploying XML, web services, and Service Oriented Architecture (SOA) technologies to link and integrate heterogeneous applications. The technology facilitates transfer of data between DMV’s applications using standard interfaces and messaging schemas. Data Encryption DMV utilizes Triple DES encryption algorithm to encrypt selective pieces of data that are deemed confidential. MVIT currently transparently encrypt personal identifying information (PII) - such as client Social Security Numbers - stored in DB2 databases without requiring major modification to existing applications.

Page 44: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 44 of 113

CURRENT COMPUTING ENVIRONMENT Describe the agency’s current computing environment

Disaster Recovery Environment Disaster recovery for the current systems environment includes two (2) procedures. First, disaster recovery for the mainframe environment is maintained and managed by the State of Nevada Department of Information Technology (EITS); the State’s central IT unit. EITS works with other State agencies to ensure that mainframe components and related applications are recoverable from disaster. Multiple State agencies rely on this first recovery procedure. The second recovery procedure is used by DMV to recover non-mainframe mission-critical servers. Utilizing server space both in Northern and Southern Nevada, DMV replicates and shares information between the two locations for systems recovery purposes. STATE OF NEVADA ENTERPRISE INFORMATION & TECHNOLOGY SERVICES CURRENT COMPUTING ENVIRONMENT The State of Nevada Enterprise Information & Technology Services (EITS) maintains a comprehensive computing and communications facility and provides technical services and support to State agencies statewide. Primary EITS services include Wide Area Network (WAN) and Local Area Network (LAN) provision and support, IBM mainframe capacity, maintenance and support, UNIX hosting and support, data center facilities and server support services, and other technical consulting and software design, development and related services.

DMV currently has multiple applications on IBM mainframe platform. Other Windows systems run on Intel platforms. The State datacenter uses DB2, and MS SQL server database software. For modernization planning purposes, DMV anticipates utilizing EITS’s server co-location and hosting services for DMV IT operations. The primary network protocol for the State’s LAN and WAN services is Ethernet and TCP/IP with WAN components consisting predominantly of Cisco Systems equipment using Cisco Systems best practices. DMV uses EITS's statewide WAN and IBM mainframe services to support various DMV applications that are used by DMV field offices throughout the State of Nevada. For DMV modernization statewide network and communication planning purposes, DMV will continue to rely on the EITS WAN for communications. Within the RFP response, the vendor is required to indicate WAN capacity and performance requirements in support of their proposed modernization solution.

PROJECT SOFTWARE Describe the current desktop tools utilized by the agency

S.No Project Software/Tools Track/Group Remarks

1 MS Office Suite (Word, Excel, Access, Outlook, Power Point, Project, SharePoint, Visio)

All

2 WinSCP All Third Party Tool used to connect to FTP Servers.

3 WebXtender All

4 Hyena Networks/Computer Helpdesk

User and end point administration

Page 45: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 45 of 113

PROJECT SOFTWARE Describe the current desktop tools utilized by the agency

Helpdesk administration

5 Screen Print Platinum 5 All Screen Print Software

6 CMS (Phone System) John Stewart and Wannetta Bernard

Access phone switch reports for Computer Help Desk

7 CommVault Computer Helpdesk Server Tape Backup System

8 Application Extender Computer Helpdesk

9 Windows 7, Windows 2008, 2013 All Operating System

10 Cisco VPN All Desktop access from remote locations

11 Remedy All Project and Ticket Reporting System and Equipment Inventory

12 Symantec Virus Scan Enterprise All Virus

13 MDS – Microsoft Deployment Services Networks Used for Ghost Images

14 Identity Manager Computer Help Desk

Application User Administration

DEVELOPMENT SOFTWARE Review this section and provide modifications as applicable.

S.No Development Software/Tools Track/Group Remarks

1 Microsoft Visual Studio 2008/2010 Applications, FAC

2 Sybase Power Builder V12 Applications, FAC

3 Interspace Applications, FAC

Homegrown Application

4 IBM RDz Applications, Systems, FAC

IBM IDE - Used for Mainframe Access

5 Humming Bird Applications, Systems, FAC

Used for Mainframe Access

6 Crystal Reports Ver. 9/10 Applications 7 QAS Batch Software Applications,

FAC Address Verification Application

9 Dameware All Remote Access to PCs 8 Acrobat Write Pro 10 All 9 Sybase SQL Anywhere All 10 Erwin System Database Maintenance Tool

Page 46: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 46 of 113

DEVELOPMENT SOFTWARE Review this section and provide modifications as applicable.

11 PDF4Net Applications Third Party Tool used to create PDF forms/reports through ASP.NET

12 MS SQL Server 2008 R2 All Microsoft SQL Server DB Software 13 MS Team Foundation Server All Source Control Software 14 Microsoft Internet Information Services All Web Servers. 15 Adobe Acrobat X PRO Applications,

FAC Limited number of licenses for creating PDFs.

16 Microsoft SharePoint 2010 All 17 IBM CICS Transaction Server All 18 IBM DB2 All 19 IBM DB2 Connect All 20 ZEKE Operations Batch job scheduler on System Z 21 IBM Output Manager All 22 IBM Removable Media Manager Systems,

MVIT Tape Management software

22 Informatica Identity Systems Applications Fuzzy search software 23 BPF Sound Software Applications Barcoding software 24 UNI (AAMVA) Applications 25 Identity and Access Manager All Built by MVIT to authenticate and

control access to DMV applications. 26 Secure FTP polling processor Applications Built by MVIT for processing to

receive, process and return insurance data for NVLIVE

STATE RESOURCES Review the sections in the template and provide any changes or additions

within this section by referencing back to the sections in the template. Will there be a Steering Committee? Yes: X No: Will there be a Project Sponsor? If yes, who will the project sponsor be? Administrator of Management Services and Program Division

Yes: X No:

Will there be a Project Manager? Yes: X No: State Project Staff – Any limitations on their availability; i.e., specific timeframes they would not be available? If so, identify those timeframes:

Yes: No: X

Will there be a Quality Assurance Monitor? Yes: X No:

Page 47: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 47 of 113

SYSTEM REQUIREMENTS – COMPUTING PLATFORM If applicable, this section should include, but not be limited to, the following information regarding the

agency’s project platform, LAN/WAN, output requirements, etc. Conceptual Platform Architecture [Placeholder] This could be used in the RFP but MVIT has to bless it? It was agreed upon in a joint RFP/ MVIT meeting that this was a good strategy and agreeable in principle to Bill the Networking lead that supported mirrored data centers as a way to have distributed LOE and instant fail over capabilities

Page 48: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 48 of 113

SYSTEM REQUIREMENTS – TECHNICAL REQUIREMENTS If applicable, this section should include, but not be limited to, the following information regarding the agency’s

required presentation requirements, data requirements, processing requirements, reporting, architecture, programming requirements, disaster recovery, development, testing and training environment, error control,

on-line help, system interfaces, search tool, etc.

Conceptual SOA Architecture Pattern [Placeholder]

Page 49: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 49 of 113

SYSTEM REQUIREMENTS – TECHNICAL REQUIREMENTS If applicable, this section should include, but not be limited to, the following information regarding the agency’s

required presentation requirements, data requirements, processing requirements, reporting, architecture, programming requirements, disaster recovery, development, testing and training environment, error control,

on-line help, system interfaces, search tool, etc.

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

Mandatory Functionality Description

Objective: The Vendor must follow the functional requirements as set out in this formal RFP, which makes the best attempt to describe in detail the product's intended capabilities, appearance, and interactions with users, in that this particular set of mandatory functional requirements sets out the intended greenfield modernization of the entire DMV computer technology environment. The Vendor must use this particular set of mandatory functional requirements as a best-in-class attempt to set out a holistic modernization of the entire DMV computer technology environment describing what the system is supposed to do by defining functions and high-level logic.

Non-Objective:

The Vendor though appearing compliant with the mandatory functional requirements, as set out below, must not, under any circumstances, in their response to this RFP, offering below standard products, design and architecture that may appear to resolve the mandatory functional requirements, that are however old inventory with expired shelf life, or old technology, or old versions of, that are wrapped with a façade to appear new, as well as using any unfair competitive methods to do so.

Additionally, the Vendor must not price their product either for the resale or licensing of, any old, or new

Page 50: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 50 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

The Vendor though appearing compliant with the mandatory functional requirements, as set out below, must not, under any circumstances, in their response to this RFP, offering below standard products, design and architecture that may appear to resolve the mandatory functional requirements, that are however old inventory with expired shelf life, or old technology, or old versions of, that are wrapped with a façade to appear new, as well as using any unfair competitive methods to do so. Additionally, the Vendor must not price their product either for the resale or licensing of, any old, or new products, or components of, in an unconscionably an excessive extortive financial amount, for any product as set out in the essence of non-objective law. The inclusion of resale or used products is absolutely prohibited.

Scope: The Vendor needs to digest that some of the mandatory functional requirements are from a business needs perspective, while others are from a purely technical perspective. Some combine both. The business needs and technology needs are clearly set out individually in the evaluation criteria table in Section ??????.

Deliverables: The Vendor must incorporate to the best of his ability all the mandatory elements as stepped out in these mandatory functional requirements, where the intended functionality is conditional (bound by policy and standards), as well as technologically feasible and architecturally sound.

The Vendor must adhere to the security master model and security reference architecture in Security Appendix I.

Vendors must reflect within their proposal and plans their recommended approach to developing the mandatory functional requirements and accomplishing all tasks and activities identified within this RFP, wherein a requirement is an objective that must be met.

High-Level Functionality for the Proposed System:

Open System Topography

The Vendor must design the intended system as an open system that implements sufficient open specifications for interfaces, services, and supporting formats to enable properly engineered components to be utilized across a wide range of systems with minimal changes, to interoperate with other components on local and remote systems, and to interact with users in a style that facilitates portability4.

The Vendor must work with the DMV by defining specifications that demonstrate a more detailed definition where an open system is defined as a collection of interacting software, hardware, and human components, designed to satisfy stated needs, with the interface specification of components:

• Fully defined • Available to the B2C, B2B, and B2G • Maintained according to group consensus, and in which the implementations of

components are conformant to the specification. The Vendor is required to follow the Zero-tolerance security mandates in this RFP and

Page 51: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 51 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications • Fully defined • Available to the B2C, B2B, and B2G • Maintained according to group consensus, and in which the implementations of

components are conformant to the specification. The Vendor is required to follow the Zero-tolerance security mandates in this RFP and the DMV strongly advises the vendor to follow the Modular Open Systems Approach (MOSA)5, which is an integrated business and technical strategy for assessment and implementation of open systems. The Vendor must design an open system that employs modular design tenets, uses widely supported and consensus-based standards for its key Interfaces, and is subject to Validation and Verification, including Test and Evaluation, to ensure the openness of its key interfaces. The Vendor must ensure that an open systems design is a design approach for developing an affordable and adaptable open system. It derives inputs from both the technical management processes and technical processes undertaken within the systems engineering and other life-cycle processes, and in turn impacts these processes. The Vendor must ensure that the open systems design strategy should be implemented as part of the program’s overall technical approach and becomes an integral part of the program’s Systems Engineering Plan (SEP)6 and a summary in their Acquisition Strategy.

Segmentation and Highly Secure Decoupled SOA Architecture

The Vendor must adhere to all reference architectures that improve the security, the lean cost model and the performance, reliability and sustainability of the overall enterprise design also allowing future scalability and service extensibility. The new architecture must weather the ever changing landscape of technology, legislative mandates, changing Federal regulations and the needs of the public at large allowing for a quicker launches of newly offered products and services and a concise widespread response to regulatory, statutory, and federally mandated changes7.

1. The new architecture shall offer reliable and sustainable System Dynamics offering high-adaptability to offer more time-to-market Alternate Services. By the vendor incorporating a Master Model Control in the architecture will remove the necessity to make repetitive and error prone changes throughout an array of disparate systems.

2. The new architecture in order to conform to System Dynamic principals shall adopt a modern user created business rules management, leveraging a consolidated rules-agent and policy management based systemic approach.

3. The new architecture shall incorporate a Consolidated Source Management System with the ability to tracking source code changes (JIT to enable single source migration, source-code management and increase production efficiencies.

4. The new architecture shall incorporate Consolidated Project Management and Application Tracking to increased productivity by seamlessly managing program development, project reporting, document versioning control, requirements gathering, technical specifications gathering, project dashboards, and work assignment, must be tracked manually. The intended consolidated project management system shall create efficiencies in the project development lifecycle including the ability to better man-age timelines, business requirements and work assignments.

5. The new architecture shall incorporate additional tool functionality to automate and integrate multi-level testing, deep forensics system monitoring, disaster recovery integration with Nevada safety systems, and all autonomous related Security features that indemnify the DMV as an Enterprise within an Enterprise.

Page 52: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 52 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

lifecycle including the ability to better man-age timelines, business requirements and work assignments.

5. The new architecture shall incorporate additional tool functionality to automate and integrate multi-level testing, deep forensics system monitoring, disaster recovery integration with Nevada safety systems, and all autonomous related Security features that indemnify the DMV as an Enterprise within an Enterprise.

Suggested De-coupled SOA architecture

SOA Architecture / Policy Requirements

The Vendor must ensure that the architecture adheres to the following umbrella policy requirements. 1. Service Oriented Architecture (SOA) – Use of Service Oriented Architecture design principles and approaches 2. Interoperability / Interfaces – Provision for compliance with interoperability standards and interfaces with internal and external systems 3. Scalability and Extensibility – Solution will need to be highly scalable and highly

Page 53: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 53 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

Requirements 1. Service Oriented Architecture (SOA) – Use of Service Oriented Architecture design principles and approaches

2. Interoperability / Interfaces – Provision for compliance with interoperability standards and interfaces with internal and external systems

3. Scalability and Extensibility – Solution will need to be highly scalable and highly flexible and extensible for ease of maintenance and response to changing future needs and technologies 4. Performance – The solution has to perform to specific standards for different type of transactions and user requests 5. Regulatory / Policies – The solution will have to address a number of State and Federal regulations and policies as highlighted in this section 6. Audit / Compliance - Comprehensive audit trail and compliance alerts

7. Usability – Highly user friendly system that leverages the UX2014 standards and complies with Federal accessibility requirements

The Vendor must ensure that the architecture adheres to the following high-level capability requirements.

The Vendor must design the proposed system as a SOA platform that enables service levels, future upgrades, replacement, and augmentation allowing the system to be incrementally modernized throughout its life span to enable the system to fit the future DMV needs.

SOA Capabilities and Key Features

1. Integrated Privilege: • Ability to transform and consolidate the current privilege eligibility and

enrollment functions to a consumer-centered profile PII model that incorporates a customer registry and an electronic case record that improves both user and consumer experience that will include:

o Simplifying and consolidating customer eligibility rules to be based on fewer criteria that can be more easily utilized across agencies and counties and enable by flexible, adaptable, extensible and easy to use rules engine that can serve all the State’s programs

o Providing for robust citizen self-service one-stop-shop through multi-channel use of technology and automated validation and verification

o Enabling eligibility determination to be completed by the appropriate person(s) in real-time or near real-time with automated validation and verification for all DMV programs, with staff intervention only where requested or required by program policy

• Modernizing eligibility systems technology to enable the streamlining of criteria and enable ease of future changes to rules

• Hosting eligibility criteria in a transparent, collaborative manner that allows for updates to criteria.

• Providing for the transfer of all DMV eligibility, enrollment, and disenrollment information between AAMVA options as well as other agencies and departments within the State of Nevada.

• Automating notices and alerts. • Adding controls to provide for more accurate processing and support

comprehensive quality monitoring program.

Page 54: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 54 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

departments within the State of Nevada. • Automating notices and alerts.

• Adding controls to provide for more accurate processing and support comprehensive quality monitoring program.

2. DMV/Customer Look-Up: • Ability to conduct DMV/Customer look-up, search and view query results -

allow identification of a citizen and their family across programs and jurisdictions

• Master Customer Index, “White Pages”, with summary and demographic information

• Identification of DMV program enrollment and current services • Ability to retrieve data from existing, electronic sources including scanned

documents to streamline the application and renewal processes, minimize duplication of effort, and reduce the overall paper work involved

3. Service Collaboration: • Common customer service integration and prevention of duplication

• Ability to support outcome-focused case management

4. Scheduling:

• Ability for customers to schedule appointments • Ability to use resource calendars, which define appointment availability, when

assigning appointment times

5. Data Sharing and Analytics:

• “Pushed” – Notices, alerts and decision support capabilities • “Pulled” – Reporting and further decision support capabilities

• Reduce the time required to gather, process and share information that is necessary for the provision of services and benefits, and the reporting on those services and benefits

• Increase the accessibility to population-based anonymous but granular data for research and public consumption

• Provide for Forecasting and Trend Analysis needs for all federal, state and local agencies and agency partners

• Enhance capacity to do “predictive modeling” and “what if” scenarios to support program and policy development

• Address data definition, transformation, integrity and quality issues for consistency across programs, agencies and jurisdictions

• Leverage current data staging, data warehouse and business intelligence (BI) initiatives to move forward with an “enterprise” approach to decision support

Page 55: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 55 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

6. Privacy and Security: • Controlling access to data to ensure privacy and security in compliance with all

applicable state and federal regulations • Centralized User Account Management, Authentication and Authorization, and

User Provisioning • Centralized Consent Management services

• Strengthened security, audit trails, quality assurance and fraud, and abuse prevention and detection

7. Interoperability / Reusability: Ability to interface or integrate with other service delivery systems internal and external to the State’s Agencies Ensure that the proposed enterprise data interchange, aggregation and analytics solution(s) coexist well with existing agency systems by being based on national standards for interoperability and data sharing thus protecting existing investments, applying national standards in Nevada and supporting incremental adoption of an enterprise approach to data sharing and shared analytics to strengthen decision making capabilities Utilizing today’s technology and incorporating industry standards to provide a modern system with components that can be easily changed, combined, and reused to meet current and future needs for more efficient, transparent, public safety products

Consolidate All Current Manual Core Services on a SOA Shared Service Layer Governance Infrastructure

The Vendor must design Master Data driven SOA architecture to integrate, share, unbundle and fully-automate all current disparate core manual services supporting the management and fulfillment of all agency services offered, where technologically feasible, or at a minimum transition to semi-automated shared services, currently including, but not limited to

(1). Department of Motor Vehicles Driver License, Motor Vehicle Registration and Title Requisition and Issuance Management

(2). Motor Carrier Trucking & Vehicles User Licensing and Forms, Trip Permits, and Oversized/Overweight Permits Requisition and Issuance Management, and

(3). Fuel Industry Online Tax Returns and Collections, Rates and Tax Forms Publishing, Potential Fuel Tax Evasion Report and Distribution of Taxpayers’ Bill of Rights Requisition and Issuance Management.

Consolidate All Current Semi-Automated Core Services on a SOA Shared Service Layer Governance Infrastructure

The Vendor must design Master Data driven SOA architecture to integrate, share, unbundle and fully-automate all current disparate core semi-automated services supporting the management and fulfillment of all agency services offered, where technologically feasible, or at a minimum transition to semi-automated shared services, currently including, but not limited to (1). Department of Motor Vehicles Driver License, Motor Vehicle Registration and Title Requisition and Issuance Management (2). Motor Carrier Trucking & Vehicles User Licensing and Forms, Trip Permits, and Oversized/Overweight Permits Requisition and Issuance Management, and (3). Fuel Industry Online Tax Returns and Collections, Rates and Tax Forms Publishing, Potential Fuel Tax Evasion Report and Distribution of Taxpayers’ Bill of Rights Requisition and Issuance Management.

Page 56: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 56 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

Title Requisition and Issuance Management (2). Motor Carrier Trucking & Vehicles User Licensing and Forms, Trip Permits, and Oversized/Overweight Permits Requisition and Issuance Management, and (3). Fuel Industry Online Tax Returns and Collections, Rates and Tax Forms Publishing, Potential Fuel Tax Evasion Report and Distribution of Taxpayers’ Bill of Rights Requisition and Issuance Management.

Consolidate All Current Automated Core Services on a SOA Shared Service Layer Governance Infrastructure

The Vendor must design Master Data driven SOA architecture to integrate, share, unbundle and fully-automate all current disparate core automated services supporting the management and fulfillment of all agency services offered, where technologically feasible, or at a minimum transition to semi-automated shared services, currently including, but not limited to (1). Department of Motor Vehicles Driver License, Motor Vehicle Registration and Title Requisition and Issuance Management (2). Motor Carrier Trucking & Vehicles User Licensing and Forms, Trip Permits, and Oversized/Overweight Permits Requisition and Issuance Management, and (3). Fuel Industry Online Tax Returns and Collections, Rates and Tax Forms Publishing, Potential Fuel Tax Evasion Report and Distribution of Taxpayers’ Bill of Rights Requisition and Issuance Management.

Enterprise Service Bus (ESB)

The Vendor must design a highly-available device providing basic message transport. The Vendor must ensure that a Message Broker can function as a complete integration hub by performing a wide range of transformation operations on message data, and apply rules and policies in flight.

The Vendor must ensure the ESB can do the above in a highly robust operating environment, delivering high scalability and throughput, hot deployment of updates, and ease of management for even very large deployments.

Master Data Management (MDM) Hub

The Vendor must design the MDM Hub management architecture to incorporate pre-designed data from the master data model to execute in the unique data model requirements of the ERP-CRM, ODS, EDW and BI domains guaranteed by MDM governance, maintaining transparency and sustainable quality. The SOA will be Master Data driven not Event driven in that the Master Data represents the role and unique PII.

Page 57: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 57 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

Suggested unlimited Fed and State Interface MDM Hub Model

The Vendor must adopt the suite strategy, or similar, when application suites that are not of the same data and/or process model coexist. The Vendor must adopt the concept of an Active Data Model to standardize references to the data allowing multi-application use of the same core data allowing open source data integration to supply Domain Driven Integration as currently found in DMV.

Page 58: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 58 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

Suggested MDM hub – Master-data driven SOA

External Interfaces The Vendor must incorporate and continue to support external interfaces as specified by the department. The external interfaces include but not limited to the following:

All American Association of Motor Vehicle Administration (AAMVA) interfaces • Justice link (JLINK)

• National Sex Offender Registry (NSOR) • Nevada Citation and Accident Tracking System (NCATS)

• Nevada Secretary of State • Nevada Controller’s Office

• Nevada Department of Taxation • Kiosks/ITI

• Nevada Operations of Multi-Automated Data Systems (NOMADS) • Complete Vehicle Identification Number Analysis (CVINA)

• Motor Vehicles Industry Portal (MVIP) • Quality Address Systems (QAS)

• Emission stations • Facial recognition

• Card production center • Electronic Payments using various payment channels and types

• Records web services (including records portal)

Page 59: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 59 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications • Emission stations • Facial recognition

• Card production center • Electronic Payments using various payment channels and types

• Records web services (including records portal) • Electronic Commercial Driver License

Internal Interfaces The Vendor must incorporate and continue to support internal interfaces as specified by the department.

The internal interfaces include but not limited to the following: • Scanning system (High Desert)

• Queuing system (Qless) • Driver knowledge test system (STS)

• Driver vision test system (Optec) • Case management system (iSight)

• Call center (AVAYA) • Electronic Lien and Titling (ELT) System

• Electronic Dealer Report of Sale (EDRS) System • Electronic Lien and Titling (ELT) System

• Electronic Dealer Report of Sale (EDRS) system • Temporary Placards (OpSec) system

Accurate and Self-Help Serviceable Knowledge Inter-Change

The Vendor must design to provide interactive self-help processes, such as kiosks, but not limited to, that improve the availability of records attached to a unique individual PII as well as streamlining all the corresponding business processes delivering instant records and documented accountability. This intended service shall give the end users the ability to easily access accurate information needed to provide on-demand customer profile surveys allowing the Department the ability to remove unnecessary redundant business processes and visits thus reducing costs and time on the customer to DMV interactions8.

Integrating Social Networking Features

The Vendor must design customer interfaces leveraging alternate technologies that we use habitually on our social networking platforms such as offering real-time chat9 and inter-active video conferencing as well as image driven electronic transaction processing similar to online mobile banking or payments such as ePay or Apple Pay.

Providing Educational Portals

The Vendor must design outreach customer interfaces to promote self-sufficiency and to provide accessible and intuitive educationally based products, services, as well as clear and understandable notifications of changes to motor vehicle laws by leveraging self-help tools to improve public safety awareness for drivers and their skill sets using alternate technologies10.

Page 60: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 60 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

Consolidating the DMV Shop Front

The Vendor must design a system capable of consolidating and enforcing transparency for all mobile, kiosk and desktop browser based applications be they windows based, web based11 or UNIX based avoiding duplication, stale data and errors and duplications.

Case Management / Business Process Management

The Vendor must implement a flexible customizable platform case management portal with a mobile-optimized interface that allows investigators to update cases and input data on any device from anywhere using an internet connection. The Vendor must ensure that the portal provides a case management solution that tracks investigations to the highest degree of confidentiality involving workplace misconduct, security incidents, criminal activity, DMV fraud or large-scale embezzlement of revenues. Vendor must also implement Case Management as part of the BPM with the capability to store all incident reports and complaints, that once entered, are queued and assigned as case files wherein the case file becomes the system of record, capturing all the steps in the lifecycle of the case, from the decision to investigate and analysis of scope to asset recovery.

Vendor must ensure that in the case a cloud is part of the implementation that all the services are maintained within the boundaries of the USA.

Interfacing with State Agencies

The Vendor must design a system capable of secure interfaces with law enforcement to comply with Federal programs enabling the State to capitalize on nearly million dollar subsidies offered annually through Federal grants12.

Rules Engine/Policy Administration

The Vendor will deliver a flexible, configurable rules driven platform managing end-2-end policy administration with an intuitive portal allowing a consolidated view of policy, product and ownership.

The Vendor will incorporate workflow driven business rules processing with real-time tracking and reporting.

Maintaining Compliance

The Vendor must design a system capable of allowing the Department to respond effectively to any and all compliance and enforcement requirements of motor vehicle laws using efficient case management therefore avoiding Federal and State penalties and disruption of the DMV administration of its own Agency as well as drastically reducing repeat criminal activity13.

Consent Management

Vendor must design a highly granular consent management tool that allows DMV technicians to segment sensitive DMV information under control and audit conditions to manage and observe the lawful usage of electronic records. Vendor must design a highly granular consent management tool that imprints electronic signature capabilities into the intended workflow of authorizations and escalations of processes.

Easing of Service Operations

The Vendor must design a system capable of delivering optimal services to Nevadans doing business with us electronically, using kiosks and other mobile electronic devices, as well as those who visit our field offices offering additional industry standard alternate services.

The intended new system shall allow for quicker customer-ready launching of new offered products and services while simultaneously delivering a faster and more accurate governed quality response to regulatory, statutory, and federally mandated changes; as well as seamlessly updating of transaction processing14.

In addition, adoption of highly maintainable decoupled systems shall enable faster

Page 61: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 61 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

alternate services. The intended new system shall allow for quicker customer-ready launching of new offered products and services while simultaneously delivering a faster and more accurate governed quality response to regulatory, statutory, and federally mandated changes; as well as seamlessly updating of transaction processing14. In addition, adoption of highly maintainable decoupled systems shall enable faster adoption of new technologies, improving security to zero tolerance and zero incident levels, as well as improving existing functionality of the current online, mobile and kiosk channels, allowing for the tracking of all crucial business processes, provide better processes for our front end users, allow us more flexibility, save time for our customers and staff, and remove the backlog DMV is currently faced with.

Delivering Low Maintenance

The Vendor must design a system that provides automated testing15 to some degree is crucial for the implementation of new functionality. Further, an integrated system with concise monitoring tools will provide end-to-end problem identification, ability to diagnose problems with automated monitoring system help, and with the monitoring of system health. Automated monitoring will allow for system exception and fault analysis, which when reviewed will allow for a proactive monitoring and issue correction. This will not only provide the Department with the tools necessary to function, but provide peace of mind to the public who rely on the security, accuracy, speed and flexibility of those functions offered by the Department either electronically or on-site.

Inter-Divisional Commerce and Revenue Management

The Vendor must design a system that provides automated seamless application and repository systems needed to track and distribute the billions in revenues the DMV is obligated to collect including the ability to track customer correspondence, maintain or predict inventory levels, and provide or derive analytics and statistics in an expedited manner replacing current manually driven business processes which are prone to error, not user-friendly between Divisions16 and which are difficult to audit. The new interface for the intended application and repositories layer must also vastly improve DMV’s ability to track and collect monies owed especially focusing on bad debt collection with the ability to arrange payment plans for those customers experiencing a hardship in repaying the debt where automated inventory controls will have a positive impact on revenue.

Delivering Lean Auto-Tested Enhancements

The Vendor must design a system that provides the ability to test all changes and enhancements automatically as all changes and/or enhancements must be tested multiple times to ensure no-faulty functionality makes its way into Production17. The DMV MVIT must keep up with existing programming challenges as well as implementing the changes mandated by legislature and/or Federal Regulation or enhancements needed to keep up with demand. This intended new system cannot cause any backlog of fixes and enhancements which would severely hinder the level of services and offered products available to Nevadans.

DMV maintaining Skills and Qualified Workforce

The Vendor must design a system that provides for cross-functional transferrable skill sets enabling the enlargement of employee candidate resource recruitment18.

Page 62: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 62 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

Workforce Development, Training and Testing

The Vendor must design an integrated virtual world approach to employee development including but not limited to web-conferencing, social networking, podcast, blog, microblogs in an integrated collaboration environment and collaborative workspace where media sharing, authoring tools, instructional tools as well as M-learning (mobile) devices are available. The Vendor must design an initial employee training portal array with integrated screens and sanitized data to initiate all the DMV services from a top down and a bottom up perspective.

The Vendor must design a follow-on employee training portal array with integrated screens and sanitized data for all upgrades and job realignments from a top down and a bottom up perspective. The Vendor must provide on-site user training and complete up-to-date operational, technical, and user documentation The Vendor must design an initial testing and certification portal array with integrated screens and sanitized data to evaluate all DNV employees for the technical and business process capabilities from a top down and a bottom up perspective..

The Vendor must design an onboarding and screening portal array with integrated screens and reference links to evaluate all future DNV employees for their eligibility, technical and business process capabilities from a top down and a bottom up perspective.

Configuration Managed Workflow Management (SDLC)19

The Vendor must design a system capable to integrate the functionality supporting configuration managed automated control and monitoring of the Front and Back Office workflow process when processing multiple types of Driver License, Registration and Title documents Trucking & Vehicles User Licensing and Forms, Trip Permits, and Oversized/Overweight Permits according to pre-defined approval and other business rules, incorporating customer notifications, scheduling, etc.

BI Analysis and Reporting Dashboard Portal

The Vendor must design a system capable to integrate the functionality supporting a potentially broad range of areas including, but not limited to, security monitoring and control of systems and users, document processing quality and control, staff, appointment and service office resource management, etc., using real-time data with supporting graphics based dashboards with all transactions available from throughout the entire DMV system ubiquitously.

The Vendor should employ real-time data visualization methods on the core data creating a visual descriptive statistics platform.

The Vendor must meet the business standard that visualization methods offer in that effective visualization helps users in analyzing and reasoning data and evidence consequences. The Vendor BI platform must be able to deliver complex data that is highly accessible, understandable and usable to the user community allowing the measuring and dissection of patterns or relationships in the data for one or more variables.

Electronic Document and Records Management System (EDRMS)

The Vendor must design a system that complies with the generic Model Requirements for the Management of Electronic Records for the State of Nevada

a) All standard file formats currently envisaged will be storable in the database b) Ability to store single documents with up to at least 10GB in size

c) Full text indexing to be carried out in the document types (MS Office formats, Adobe suite formats, OpenDocument format) most frequently used by the DMV.

d) Guarantee of the authenticity of stored documents

Page 63: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 63 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

Records Management System (EDRMS)

a) All standard file formats currently envisaged will be storable in the database b) Ability to store single documents with up to at least 10GB in size

c) Full text indexing to be carried out in the document types (MS Office formats, Adobe suite formats, OpenDocument format) most frequently used by the DMV.

d) Guarantee of the authenticity of stored documents e) Administration of physical paper archives. The creation of registration cards2 must include metadata on title, subject, location, confidentiality, retention and volume and produce a visible unique identifier for the document.

f) Interfaces to common backup software, compatible with DMV MVIT system requirements.

g) Physical file storage on disks, compatible with DMV system requirements. The Vendor must additionally design a template management system to fulfill the crucial role in internal and external communication risk management of the DMV agency’s documents, permits, licenses, reports to the extent of official state letter headed stationary including any document that has a fiscal purpose. The Vendor must design a template-based management library system that ensures compliance with Nevada state standards specifically in formatting and discrete disclosures and embedded protective measures. That all templates must have a control reference and an expiry date. Additionally the Vendor must include establish in his design a transparent chain of individual responsibility around approval of text, legal and regulatory compliance, all with a well-defined segregation of duties which is able to be subjected to an audit trail.

Imaging The Vendor must design a system capable to integrate a user friendly scanning application to the EDRMS to capture and store customer information as mandated by Nevada Revised Statutes (NRS)20. Currently the Department has a disparate software system which is used to scan and maintain hard-copy documentation.

The Vendor must ensure that scanning applications are user friendly, operate efficiently time-wise, that provide real-time search capabilities, allowing for fast customer issue resolution. Vendor must ensure that the scanning capability provides a high quality product for investigations launched by Compliance Enforcement. Vendor must design scanning as part of an integrated system in line with State regulations governing scanning.

Increased Network Security

The Vendor must design a network system capable to integrate the functionality of contemporary devices such as VLANs, IEEE 1613 specified Multiplexing, HTTP/2 and SPDY 4.0, RIFD Technology, etc.

Identity Management / Single Sign-On (SSO)

The Vendor must provide all users of the intended system with unified sign-on and authentication across all their enterprise resources, including mobile and pad devices, kiosks, desktops, client-server, custom tools and host-based SOA applications. The Vendor must provide a centralized framework for security and compliance enforcement linked to a discrete BI portal. The Vendor must eliminate the need for multiple usernames and passwords.

The Vendor must enforce strong password and authentication policies.

Page 64: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 64 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

enforcement linked to a discrete BI portal. The Vendor must eliminate the need for multiple usernames and passwords.

The Vendor must enforce strong password and authentication policies.

Enterprise Portals The Vendor must provide an Enterprise Portals infrastructure providing access to, and interaction with, relevant information assets (information/content, applications and business processes), knowledge assets and human assets, by select targeted audiences, delivered in a highly personalized manner. The Vendor must provide both types of Portals in SOA:

• Vertical portals focus on accessing specific applications or business functions; • Horizontal portals seek to integrate and aggregate information from multiple cross enterprise applications, as well as specific line-of-business tools and applications.

Suggested Enterprise Portal Architecture

Sustainability The Vendor must design the system to maintain all functional levels of Sustainability as cited below and present its corresponding solutions for each of these states to DMV: • Combat Resistance: User resistance is a salient reason for the failure of new systems

and hence needs to be understood and managed • Build Failure-Resistant Systems (FRS): A system-level cross-layer approach to

reliability, encompassing failure mechanisms of all types of components, that has the potential to deliver high reliability with significantly lower power and performance overheads than current single-layer techniques. By distributing reliability across the system design stack, cross-layer approaches can take advantage of the information available at each level, including even application-level knowledge, to efficiently tolerate errors, aging, and variation. This will allow handling of different physical effects at the most efficient stack layer, and can be adapted to varying application needs, operating environments, and changing hardware state.

• Resilience Architecture: Requires architecture that supports interfaces for multi-level cooperation. Creating SOA abstraction layers that hide unnecessary details

Page 65: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 65 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

knowledge, to efficiently tolerate errors, aging, and variation. This will allow handling of different physical effects at the most efficient stack layer, and can be adapted to varying application needs, operating environments, and changing hardware state.

• Resilience Architecture: Requires architecture that supports interfaces for multi-level cooperation. Creating SOA abstraction layers that hide unnecessary details from other layers of the (hardware) stack while communicating critical information (up and down the stack) about reliability and errors; designing interfaces that allow software to communicate reliability needs, types of errors that can be tolerated, invariants that should hold under correct operation, and capabilities for managing errors to hardware; and techniques that allow hardware to communicate its state to software without requiring that the software understand the details of the hardware design.

• Increase Cross-Layer, Differential and Scalable Adaptive Reliability: One cause of reduced reliability of electronic computing systems is the increasing probability of device failure as feature sizes of integrated circuits are reduced. Further reliability concerns arise beyond reduced device reliability and increased parameter uncertainty. The coupling between densely integrated components, circuits, packaging, and sub-systems is often too complex to be fully considered in the design. Thus, failure might be caused by either design errors (or poor designs) or operational conditions. For many systems, designers will be concerned with graceful degradation at the application level, recovery from transient and permanent errors, and robust behavior at the system level.

• Avoiding Disruptive Multiple-Equilibrium Dynamics: caused by sudden shifts in expectations in that multiple equilibria gives rise to a range of scenarios, each quite different and each with its own distribution of returns, risks, correlations, and functionality. In assessing the possibility, duration and impact of systemic risk factors, we need to analyze the endogenous and exogenous interaction of expectations.

• Systemic Risk: arises due to excessive leverage and risk taking induced by free-riding externalities.

Application Server and Secure Data APIs

The Vendor must design where required a full set of secure Application Protocol Interface (API) to access data internally by other government agencies as well as via the web by external and public parties similar to DPAPI or OAG.

Database Management System

Vendor will ensure that all rules and regulations that govern data collection, storage and use are rigorously applied and enforced

Data Integration / ETL

Vendor will ensure that DMV data will be continuously reviewed and there will be a relentless focus on ensuring the highest quality of data content with specified data owners accountable for quality and establishing standards for data stewardship; addressing data definition, transformation, integrity and quality issues

Transaction Monitoring / Logging

Vendor will ensure that transactional information captured across the program domains must be real-time monitored, integrated and accessible as well as recorded in an SDLC managed logging database.

Vendor will ensure the leverage of all data across end-2-end systems and processes takes into account security, privacy and confidentiality considerations

Vendor will maintain consistent definitions and a single authoritative source of record for all end-2-end core, compromised and garbage data.

Page 66: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 66 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

managed logging database. Vendor will ensure the leverage of all data across end-2-end systems and processes takes into account security, privacy and confidentiality considerations Vendor will maintain consistent definitions and a single authoritative source of record for all end-2-end core, compromised and garbage data.

Vault Technology The Vendor must design a secure Vault Platform providing sophisticated unified security management and administration controls, a unique, time-based reporting environment running in a world-class SSAE 16 SOC 1 Type II Certified Data Center with SysTrust Certified Security. The Vendor must design a Vault security management system that covers at a minimum real-time asset inventory control, active and passive network scanning and monitoring, as well as vulnerability assessments, testing and monitoring, IDS and file threat detection supplying security intelligence such as SIEM correlation, incident response, reporting and alarms. MDM and Containerization Deployed on the Same Device

The Vendor must add a layered approach to security by adopting a hybrid model with several different management approaches. Containerization provides an extra barrier to access DMV sensitive content. MDM and containerization could reside on the same device or separately. Vendor must consider that the DMV is plagued with highly sensitive proprietary content and strictly regulated information that cannot be breached. The Vendor must design at minimum a SSO managed device architecture that provides a fundamental barrier. In addition the Vendor must also consider an extra barrier to access DMV Agency content forcing users to be required to enter both a device-level passcode and a container-level passcode, and administrators have both device-level controls and application-level controls that enable app-to-app collaboration with other managed and secure applications within the container (see: MSO in Desirable Functional Requirements below). The Vendor must extend the Vault technology to an Enterprise Mobility Management Platform, which Vendor must design to allow DMV to monitor the entire deployment of mobile apps through a single lens to catch potential security breaches before they become major issues. The Vendor is tasked to design a secure mobile platform using containerization stability to continually add users and deploy content and scalable applications.

The Vendor must incorporate the highest standards of encryption including or similar to, but not limited to:

Functional Encryption Methods

NIST: Special Publications 800-111, 131A, 57, Part 1, CMVP Validation List

Algorithm Min Key Length Use Case

AES 128 Data Encryption

RSA 2048 Digital Signatures/Public Key Encryption

ECDSA 224 Digital Signatures/Public Key Encryption

SHA 224 Hashing

• NSA insertion of Dual_EC_DRBG (in response to Snowden hack)

Page 67: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 67 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

ECDSA 224 Digital Signatures/Public Key Encryption

SHA 224 Hashing

• NSA insertion of Dual_EC_DRBG (in response to Snowden hack) • Advanced Encryption Standard (AES): symmetric block cipher used by the U.S. government to protect classified information implemented in software and hardware to encrypt sensitive data.

• Un-decodable Encryption Schemes and Barcodes: bit secure ciphertext • Federal Register (FR): contains government agency rules and proposed rules.

SANS 20 Critical Security Controls: industry-accepted best practices for cyber defense, minimum standard Data Protection Level (DPL) 0-3

HP 256-bit key Atalla Cloud Encryption: ESSIV Schema, Cipher-Block Chaining (CBC)

HIPAA: Under the HIPAA Security Rule, there are two implementation standards related to encryption:

• Encryption and Decryption - 164.312(a)(2)(iv): Implement a method to encrypt and decrypt electronic protected health information.

• Encryption - 164.312(e)(2)(ii): Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.

Tools The Vendor must integrate specialized tools with standard interfaces that add value to the DMV process, without compromising security and performance.

The Vendor must use where needed enterprise wide tools to provide reliable and cost effective data sources for the records managed by each DMV Field Agency and their partners.

Desirable Functionality

Description

Objective: The Vendor must follow the functional requirements as set out in this formal RFP, which makes the best attempt to describe in detail the product's intended capabilities, appearance, and interactions with users in that this particular set of mandatory functional requirements sets out the intended greenfield modernization of the entire DMV computer technology environment. The Vendor must use this particular set of desirable functional requirements as a best-in-class attempt to set out a holistic modernization of the entire DMV computer technology environment describing what the system is supposed to do by defining functions and high-level logic.

Scope: The Vendor needs to understand that some of the desirable functional requirements are from a business needs perspective while others are from a purely technical perspective. Some combine both. The business needs and technology needs are clearly set out individually in the evaluation criteria table in Section ??????.

Page 68: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 68 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

and technology needs are clearly set out individually in the evaluation criteria table in Section ??????.

Deliverables:

The Vendor must incorporate to the best of his ability all the desirable elements as stepped out in these functional requirements, where the intended functionality is conditional (bound by policy and standards), as well as technologically feasible and architecturally sound. The Vendor must adhere to the security master model and security reference architecture in Security Appendix I. The Vendor must reflect within their proposal and plans their recommended approach to developing the required desirable functional requirements plans and accomplishing all tasks and activities identified within this RFP, wherein a requirement is an objective that must be met.

Identity Management / Multiple Sign-On (MSO)

The Vendor must design a MSO so that users are required to enter both a device-level passcode and a container-level passcode, and administrators have both device-level controls and application-level controls that enable app-to-app collaboration with other managed and secure applications within the container. Keys to the lower level sign-on would be kept in Escrow.

Integrating Specialized 3rd Party Educational Portals

Other Niche Areas The Vendor must design and integrate where possible niche applications and tools that manages the enterprise from specific standalone and small quantity user perspectives that do not necessarily come under the enterprise umbrella.

Consolidate All Current Manual Ancillary or Extraneous Services on a SOA Shared Service Layer Governance Infrastructure

The Vendor must design SOA architecture to integrate, share, unbundle and fully-automate all current disparate core manual services supporting the management and fulfillment of all agency services offered, where technologically feasible, or at a minimum transition to semi-automated shared services, currently including, but not limited to

(1). Department of Motor Vehicles Driver License, Motor Vehicle Registration and Title Requisition and Issuance Management

(2). Motor Carrier Trucking & Vehicles User Licensing and Forms, Trip Permits, and Oversized/Overweight Permits Requisition and Issuance Management, and

(3). Fuel Industry Online Tax Returns and Collections, Rates and Tax Forms Publishing, Potential Fuel Tax Evasion Report and Distribution of Taxpayers’ Bill of Rights Requisition and Issuance Management.

Consolidate All Current Semi-Automated Ancillary or Extraneous Services on a SOA Shared Service Layer Governance Infrastructure

The Vendor must design SOA architecture to integrate, share, unbundle and fully-automate all current disparate core semi-automated services supporting the management and fulfillment of all agency services offered, where technologically feasible, or at a minimum transition to semi-automated shared services, currently including, but not limited to

(1). Department of Motor Vehicles Driver License, Motor Vehicle Registration and Title Requisition and Issuance Management

(2). Motor Carrier Trucking & Vehicles User Licensing and Forms, Trip Permits, and Oversized/Overweight Permits Requisition and Issuance Management, and

(3). Fuel Industry Online Tax Returns and Collections, Rates and Tax Forms Publishing, Potential Fuel Tax Evasion Report and Distribution of Taxpayers’ Bill of Rights Requisition and Issuance Management.

Page 69: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 69 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

Layer Governance Infrastructure

Title Requisition and Issuance Management (2). Motor Carrier Trucking & Vehicles User Licensing and Forms, Trip Permits, and Oversized/Overweight Permits Requisition and Issuance Management, and (3). Fuel Industry Online Tax Returns and Collections, Rates and Tax Forms Publishing, Potential Fuel Tax Evasion Report and Distribution of Taxpayers’ Bill of Rights Requisition and Issuance Management.

Consolidate All Current Automated Ancillary or Extraneous Services on a SOA Shared Service Layer Governance Infrastructure

The Vendor must design SOA architecture to integrate, share, unbundle and fully-automate all current disparate core automated services supporting the management and fulfillment of all agency services offered, where technologically feasible, or at a minimum transition to semi-automated shared services, currently including, but not limited to (1). Department of Motor Vehicles Driver License, Motor Vehicle Registration and Title Requisition and Issuance Management (2). Motor Carrier Trucking & Vehicles User Licensing and Forms, Trip Permits, and Oversized/Overweight Permits Requisition and Issuance Management, and (3). Fuel Industry Online Tax Returns and Collections, Rates and Tax Forms Publishing, Potential Fuel Tax Evasion Report and Distribution of Taxpayers’ Bill of Rights Requisition and Issuance Management.

Master Data Management (MDM) Ecosystem Ready

The vendor must design a Master Data Management(MDM) Ecosystem Ready Architecture:

MDM Ecosystems are much more involved than the simple MDM hub architecture consisting of upstream, downstream and core components. The data also has to be architected into core data, compromised data (non-core) and garbage one time usage data in a master data model.

The MDM ecosystem encompass the following topography: • Interface and Workflow services

• Repository Services • Data Quality Services

• Integration Backbone The MDM ecosystem treats:

• Sources: Source systems capture raw materials (data) used to build the master record

• Centralized data management factories: Technologies and processes to collect, standardize, consolidate, aggregate, and apply business rules leading to the finished product (master data).

• Business processes, systems, and access tools: Package and deliver master data to support contextual business consumption.

• Transportation systems: Information integration technologies ensure data seamlessly navigates through these components.

Page 70: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 70 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

The Vendor must design a Cloud Ready Social Architecture: Social Architecture is defined as [SRI Think-tank]; Management of decoupled components that interface with social networks at a B2C, B2B and B2G criteria that deal with issues of privacy, public policy and advanced security such as Vaults.

The Vendor shall define Business Productivity Components: 1). Business Process Outsourcing (BPO); contracting of the operations and responsibilities of a specific business process to a third-party service provider. BPO is typically:

(a). back office outsourcing, which includes internal business functions such as human resources or finance and accounting, and

(b). front office outsourcing, which includes customer-related services such as contact center services.

BPO that is contracted outside a company's country is called offshore outsourcing. BPO that is contracted to a company's neighboring (or nearby) country is called nearshore outsourcing. Often the business processes are information technology-based, and are referred to as ITES-BPO, where ITES stands for Information Technology Enabled Service. Knowledge process outsourcing (KPO) and legal process outsourcing (LPO) are some of the sub-segments of business process outsourcing industry.

2). Productivity Platform Suite (PPS); includes Business Software-plus-Services [Online Exchange, Online Content Management, Online Communications, end-user self-service capabilities, and Real-time Meeting] approach enables organizations to access the capabilities of enterprise software through on-premises servers, as online services, or a combination of both, depending on specific business requirements. Services also provide the option to add complementary capabilities that enhance on-premises server software and simplify system management and maintenance.

3). Customer Relationship Management (CRM); facilitates communication around client and account activities.

4). Security; protect information with advanced capabilities. Deploys anti-malware and anti-spam filtering to principally protect mailboxes. Employs data loss prevention capabilities thus preventing users from mistakenly sending sensitive information to unauthorized people. Maintains globally redundant servers, premier disaster recovery capabilities, and allows teams of security forensic experts to monitor the target system around the clock safeguarding the data and metadata with a guaranteed 99.9% uptime, including a guaranteed financially-backed service level agreement supporting constant running email and other communication devices.

Cloud Ready

5). Shareable Online File Storage System; a service that users can store and share documents, photos and links that allows users to access their files from anywhere with an Internet connection, including on mobile devices. With file sharing, users can also choose which files they want to share with contacts, make public or just keep private. You can control the permissions in online storage to regulate who can view and/or edit shared documents.

Page 71: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 71 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

shared documents.

The Vendor shall define Cloud Social Connectors:

• Social Networks • Professional Networks

• Open Business Clubs

The Vendor shall define Cloud Infrastructure Services:

• Shared Service Layer • SQL RDBMS

• BLOB storage

The Vendor shall identify and define big data goals in order that DMV decision makers can collaborate to solve problems and grow opportunities.

The Vendor shall identify the range of big data DMV might appropriate and how that can be scaled and easily scaled to provide secure shared access.

The Vendor shall scope the type of unstructured data that DMV may leverage

Big-Data Analytics Ready

The Vendor shall define industry leading capacity and performance for big data

workloads.

Mandatory Excluded Description

Objective:

The Vendor must follow the mandatory excluded functional requirements as set out in this formal RFP to protect the DMV from using malware, bad code, unsupported specifications, and non-standard architecture that could severely harm and jeopardize the product's intended capabilities, appearance, and interactions with users.

This particular set of the mandatory excluded functional requirements is intended to protect the proposed greenfield modernization of the entire DMV computer technology environment from inheriting low quality and unpredictable and unsupported technology.

Scope:

The Vendor needs to digest that some of the functional requirements are from a business needs perspective while others are from a purely technical perspective. Some combine both. The business needs and technology needs are clearly set out individually in the evaluation criteria table found in Section ?????.

Deliverables:

The Vendor must not incorporate any open source software (OSS) as stepped out in these mandatory excluded functional requirements even though marketing and vendors state that they are technologically feasible and architecturally sound. The Vendor in all cases must adhere to the security master model and security reference architecture.

Vendors must reflect within their proposal and plans their recommended approach to never developing the intended system using mandatory excluded functional requirements and must be held to accomplishing all tasks and activities identified within this RFP, wherein a requirement is an objective that must be met using standardized and certified software and hardware.

Page 72: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 72 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

The Vendor in all cases must adhere to the security master model and security reference architecture. Vendors must reflect within their proposal and plans their recommended approach to never developing the intended system using mandatory excluded functional requirements and must be held to accomplishing all tasks and activities identified within this RFP, wherein a requirement is an objective that must be met using standardized and certified software and hardware.

The Vendor shall not use or develop or integrate any functionality whatsoever using Open Source Software (OSS) or other “OPEN” gadgets at any place in the architectural stack be they coarse grained or fine grained as they are not controllable and accountable under metrics published and indemnified by government agencies such as but not limited to the NSA, DoD, as well as by institutions such as but not limited to such as IEEE and ANSI as well as nationally and internationally recognized private and/or public sector governance, boards and committees as non-conforming technology poses an extreme security risk to not only the user but the interfaces the user exposes these open issues to .

• Defining Open Source Software (OSS): "software for which the human-readable source code is available for use, study, re-use, modification, enhancement, and re-distribution by the users of that software".

• Careful legal review is required to determine if a given license is really an open source software license. The following organizations examine licenses; licenses should pass at least the first two industry review processes, and preferably all of them, else they have a greatly heightened risk of not being an open source software license:

• Open source software licenses are reviewed and approved as conforming to the Open Source Definition by the Open Source Initiative (OSI). The OSI publishes a list of licenses which have successfully gone through the approval process and comply with the Open Source Definition.

• In practice, an open source software license must also meet the GNU Free Software Definition; the GNU project publishes a list of licenses that meet the Free Software Definition.

• Fedora reviews licenses and publishes a list of "good" licenses that Fedora has determined are open source software licenses.

• Debian-legal also examines licenses (for Debian) to determine if they meet the Debian social contract; the Debian license information lists licenses that are known to pass (or not pass) these criteria.

In practice, nearly all open source software is released under one of a very few licenses that are known to meet this definition. These licenses include the MIT license, revised BSD license (and its 2-clause variant), the Apache 2.0 license, the GNU Lesser General Public License (LGPL) versions 2.1 or 3, and the GNU General Public License (GPL) versions 2 or 3. Using a standard license simplifies collaboration and eliminates many legal analysis costs.

Open Source Software (OSS)

Synonyms for open source software: "Open source software" is also called "Free software", "libre software", "Free/open source software (FOSS or F/OSS)", and "Free/Libre/Open Source Software (FLOSS)". The term "Free software" predates the term "open source software", but the term "Free software" has been sometimes misinterpreted as meaning "no cost", which is not the intended meaning in this context. ("Free" in "Free software" refers to freedom, not price.) The term "open source software" is sometimes hyphenated as "open-source software

Page 73: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 73 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

source software (FOSS or F/OSS)", and "Free/Libre/Open Source Software (FLOSS)". The term "Free software" predates the term "open source software", but the term "Free software" has been sometimes misinterpreted as meaning "no cost", which is not the intended meaning in this context. ("Free" in "Free software" refers to freedom, not price.) The term "open source software" is sometimes hyphenated as "open-source software

Antonyms for open source software: Commercially-available software that is not open source software is typically called proprietary or closed source software.

Commonplace Implementation Errors & Omissions

Objective: The Vendor must make every attempt to avoid commonplace errors in architecture, design, implementation, deployment and delivery.

Scope:

The Vendor must consider the entire project management, design and implementation of the intended enterprise DMV system modernization

Deliverable: The Vendor must deliver DMV a trouble free system for the monies and time allotted.

COST vs. FUNCTIONALITY:

The Vendor must ensure SLAs and the division of the architectural budget footprint meet the expected ROI avoiding and not incurring cost overruns or undisclosed changes.

End-to-end security; lack of, and inability to conduct, an end to end security test on the production system.

The Vendor must ensure that end-to end security not just in test mode but in sustainable and reliable production mode for at least one year of ops.

Possession of a comprehensive, top-down view of the full security posture.

The Vendor must ensure that the top-down view does not lose sight of nor hide the atomic details and inherent weaknesses

Cybersquatting and Domain Name Confusion

The Vendor must ensure that web URIs and URLs are tamper, phishing, hacker, virus and spider proof.

The Insider Threat; lack of a personnel policy

The Vendor must inform DMV of all possible internal threats, weaknesses and vulnerabilities to ensure DMV’s personal policies reflect the true risks thus ensuring adequate countermeasures and enforcement of such.

Page 74: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 74 of 113

FUNCTIONAL REQUIREMENTS If applicable, this section should include the functional specifications

EDI standards The Vendor is responsible to ensure EDI standards and to plug any and all vulnerabilities

Unique identification of an individual

The Vendor must ensure PII must be 100% accuracy

Bad tracking of all stages of online activity

The Vendor must ensure transactions and logs must be optimized for accuracy and roll back of breeches and lost data as well as stored for compliance per DMV policies

Over stressed single point of access to online facade

The Vendor must ensure that the architecture is scalable and sustainable beyond simple overloads that it should be 40 to 60 times the ratio of normal business.

Separate informational survey sites from signup and processing

The Vendor must ensure that process and information are segregated for the user interfaces and not comingled that business information and business controls must be separate

System intercommunication disruption

The Vendor must ensure seamless network and fail over

Error prone eligibility results

The Vendor must ensure accurate customer and DMV employee profiling

Formal end-to-end performance testing

The Vendor must ensure formal end-to-end ad hoc performance testing

Enterprise identity management (or EIDM) function or front door

The Vendor must ensure accurate and actionable background check capability

Response time; browser processing and server response.

The Vendor must ensure best response time for web enabled and mobile client server architecture

HTTP 503 status code responses

The Vendor must ensure http 503 a non-issue

Concurrent Users The Vendor must ensure from crashes caused by user overload and peaks as well as hack attacks

SEI CMMI Level 5 The Vendor must supply actual and verifiable project references (wins and losses) not just certifications and that all vendor resumes be vetted to the fullest extent possible for criminal backgrounds and former bad behavior in previous sites.

Page 75: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 75 of 113

SYSTEM REQUIREMENTS – SECURITY STANDARDS If applicable, this section should include the security standards specific to the agency.

These are over and above the security standards in Section 4.5 which must be included in all IT RFPs.

DMV STRATEGIC SECURITY REQUIREMENTS:

OVERVIEW

DMV is obliged by Law, the wishes of the Governor and the State Legislature to meet the highest security standards in its technology platforms to meet all RISKs that could possibly effect the integrity of the State as a Steward of public data and the issuance of documents that allow the eligible public to enjoy the privilege of using the public highways and byways in Nevada legally.

Managing Global Security RISK is one of the most important sections of this RFP. Time and time again, large enterprises that once thought that their security was adequate have been proven grossly incorrect.

To meet the complete replacement of the old platform, DMV will publish and update all of its security documentation for this proposed legacy modernization based on the three basic ingredients of a security mandate’s best practices:

Security Policy and Standards: The DMV security office, for the purposes of this RFP is in the process of increasing the scope of the Nevada State security standards in response to the additional threats and vulnerabilities that modern systems are exposed to internally and externally. Part of that increased scope incorporates NRS 242, Common Criteria 3.1 Revision 4, September 2012, TOE and various DoD, FBI and NSA standards as well as Zero-tolerance security policy adoption of the Google and Amazon models.

DMV for the purposes of this RFP has set out mandatory organizational policies and standards that govern the system’s design, deployment, controls and run time; describing both what is allowed as well as what is not allowed in the system.

Security Architecture: a strategic and unifying framework employing reusable services that implement policy standards and risk management decisions (see: RA Security Appendix I21).

Security Processes: should be driven by a modern technical Security Ecosystem that is not only current but forward looking into the ever evolving landscape of hacking and viruses. The technical Ecosystem should be a living application that constantly thwarts threats and vulnerabilities and produces highly available countermeasures to protect the integrity and privacy of the State and the Public at large.

Security Metrics: measuring and monitoring standards, architecture and process to validate the hermetic seal of the system. This is based primarily on the Symantec Tenable forensics.

The technical Ecosystem will form the basis to carry out the intent of the Agency to impose well measured risk management, to be able to adhere to security policies with zero tolerance allowing the constant adoption of better and better standards as the threats evolve and new vulnerabilities require highly available and effective countermeasures.

DMV will prescribe a Security Architecture Blueprint detailing how security is managed in a modern SOA environment.

Mandatory Functionality

Description

RISK AVERSE SECURITY FUNCTIONALITY

The Vendor integrate a risk averse security model into its End-2-End architecture • The Vendor must ensure a risk management centric approach allows for the security

architecture to be Agile in responding to the business continuity and disaster aversion needs.

• The Vendor must program for risk as a function of threats exploiting vulnerabilities against assets and that the functionality must ensure that the End-2-End threats and vulnerabilities must be destroyed, contained, quarantined or at least mitigated by deploying countermeasures.

• The Vendor must guarantee that the risk management process implements risk

Page 76: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 76 of 113

SYSTEM REQUIREMENTS – SECURITY STANDARDS If applicable, this section should include the security standards specific to the agency.

These are over and above the security standards in Section 4.5 which must be included in all IT RFPs. aversion needs.

• The Vendor must program for risk as a function of threats exploiting vulnerabilities against assets and that the functionality must ensure that the End-2-End threats and vulnerabilities must be destroyed, contained, quarantined or at least mitigated by deploying countermeasures.

• The Vendor must guarantee that the risk management process implements risk assessment to ensure the Agency’s risk exposure is in line with risk tolerance goals which must be zero tolerance.

• The Vendor must incorporate agility in its approach in that behavior is not uniformly risk averse or risk seeking and it is the intent of the DMV Agency to require the vendor to offer the highest opportunities to create highly available and successful countermeasures for the proposed new platform.

• The Vendor must design the system to take on at a minimum the appropriate level of risk-averse actions based on the business goals as set out in this RFP.

IMPLEMENTING SOA FOR SECURITY:

The Vendor shall incorporate SOA architecture to meet the standard risk-averse or risk-centric approach. The Vendor will follow and respond with an equivalent Requirements model to the DMV’s four high levels of concern below: 1. Strategy Model: a description of an organization’s strategic security goals, the intended business design from a user and operator perspective, as well as clear business objectives including high-level rules: legislation, agency practices, business practices and State and Federal rules and guidelines. 2. Operational Model: a compute-independent model of business processes and rules including constraints and compliance rules with which business processes must comply (zero tolerance); some constraints will be validated at the user level whereas others will have to be verified transparently in and E2E architectural model including but not limited to from the UI, the cache, user authentication component (SSO), web services, ESBs, middleware, APIs, databases and the new back end MDM Ecosystem. 3. Execution Model: a platform-independent description of documents, flows, and connections to people, applications, and data sources and their inherent relationships (not merely superficial), including application specific rules and behavioral patterns capture; wherein security and compliance requirements must be met at this abstraction as well as all concrete realized levels. The behavioral patterns must be captured to build a role based lessons learned of any and all entities that touch the intended system.

4. Implementation Model: a platform specific model of the intended IT infrastructure, consisting of hardware, system software, cloud infrastructure, big data infrastructure, mobile infrastructure, kiosk infrastructure, as well as scripts and middleware frameworks that support the UI and channels. This must also include a platform-dependent configuration; security and compliance requirements and infrastructure realization must all be taken into account from an end to end perspective (E2E) and not just an individual domain such as Middleware or a Database. The infrastructure must present a cohesive and seamless model for all security no matter how fine grained or

Page 77: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 77 of 113

SYSTEM REQUIREMENTS – SECURITY STANDARDS If applicable, this section should include the security standards specific to the agency.

These are over and above the security standards in Section 4.5 which must be included in all IT RFPs. mobile infrastructure, kiosk infrastructure, as well as scripts and middleware frameworks that support the UI and channels. This must also include a platform-dependent configuration; security and compliance requirements and infrastructure realization must all be taken into account from an end to end perspective (E2E) and not just an individual domain such as Middleware or a Database. The infrastructure must present a cohesive and seamless model for all security no matter how fine grained or coarse grained the gadget.

TREATMENT OF MAJOR AREAS OF CONCERN

The Vendor must do everything in its power as an expert to mitigate the DMV from becoming part of the growing statistics of technology security breaches. • The Vendor when designing its functional strategy must be aware that Government

suffers from approximately 19.5% of all reported hacking incidents based on sources obtained through the Freedom of Information Act of which 60% were apparently hacks22.

• The Vendor when designing its functional strategy must be aware that the ratio of threat is approximately 70% external threat and 30% internal.

INTERNAL RISK AVOIDANCE

• The Vendor must build measures into its security offering that treat the prevalence and severity of the insider threat by:

o Denying identity fraud and/or theft of PII information;

o Denying fraudulent production of fake driver licenses and identification cards;

o Denying attempts to counterfeit and sell driver licenses and identification cards unlawfully;

o Denying the sale of valid DMV originated driver licenses and identification cards;

o Denying accepting of forged out of state or international driver licenses and identity cards;

o Denying the falsification of test results or false credentials of any third party;

• The Vendor must build measures into its security offering that treat the prevalence and severity of the insider threat by denying the issuance of any falsified titles or vehicle registration documents or fraudulent manufacturing of DMV registration decals .

• The Vendor must build measures into its security offering that treat the prevalence and severity of the insider threat by denying the fraudulent activities surrounding fuel tax evasion.

• The Vendor must prescribe means to ensure un-breachable trusted user status of all the persons, known or unknown, with access to systems and data.

• The Vendor must be aware that the trusted user status is one of the most significant risks to the security of sensitive information.

• The Vendor must be aware and prevent incidents that occur even with today’s sophisticated roles and privilege countermeasures in that the internal user poses a 30% risk, where 10% could be considered malicious.

• The Vendor must be aware of and prevent incidents found by Risk Based Security, Inc. and the Open Security Foundation’s review of insider breaches that reveal that an accidental release of information occurs almost twice as often as an intentional data compromise. [9.4% Malicious vs. 17.1% Accidental] An analysis of 3515

Page 78: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 78 of 113

SYSTEM REQUIREMENTS – SECURITY STANDARDS If applicable, this section should include the security standards specific to the agency.

These are over and above the security standards in Section 4.5 which must be included in all IT RFPs. sophisticated roles and privilege countermeasures in that the internal user poses a 30% risk, where 10% could be considered malicious.

• The Vendor must be aware of and prevent incidents found by Risk Based Security, Inc. and the Open Security Foundation’s review of insider breaches that reveal that an accidental release of information occurs almost twice as often as an intentional data compromise. [9.4% Malicious vs. 17.1% Accidental] An analysis of 3515 insider incidents revealed that malicious activity accounted for only 30.2% of all incidents23.

• The Vendor must be aware of and prevent incidents found by Risk Based Security, Inc. and the Open Security Foundation’s review of breach type in insider incidents that also yields interesting results. Accidental data loss due to activities such as errant website postings, careless equipment disposal or poor equipment management accounted for 63.6% of insider incidents.

EXTERNAL RISK AVOIDANCE

The Vendor has a requirement to protect DMV from external bad acts caused by bad design and or standard or non-standard components that the vendor recommends, integrates, implements and/or deploys such as: • The Vendor must not allow cyber-vandalism to affect the DMV

• The Vendor must not allow hacks into DMV unclassified email system. • The Vendor must not allow "cyber-security intrusion" exposing employee personal

information • The Vendor must not allow computer-hacking that causes significant security-

breaches of inter-agency computer security • The Vendor must not allow weaknesses found in 3rd party software such as, but not

limited to Microsoft DLLs, Microsoft’s Word and Excel to allow hackers to penetrate the DMV.

• The Vendor must not allow files from the DMV to be stolen.

DISCRETE PROTECTION SERVICES & REALTIME LINKS TO LAW ENFORCEMENT AND FORENSICS SPECIALISTS

• The Vendor shall provide confidentiality, integrity and availability of needed protection services for the new platform.

• The Vendor shall provide specialized and discrete services that are implemented purely as protection services, such as authentication and authorization, detection services, such as monitoring and auditing, and response services, such as incident response including state of the art forensics (it is entirely possible that the State IT may have to utilize a third party expert service and interface to disseminate threats to its network that is linked to its online and mobile presence).

• The Vendor shall ensure that the new platform allows the DMV Agency becomes an auto governed risk management body.

IMPLEMENT ZERO TOLERANT SECURITY

• The Vendor shall be responsible to incorporate Zero-Tolerance policy management functionality into its system architecture by offering zero-discretion policy services, where there is ZERO room for deviation from the absolute rule.

• The Vendor shall ensure that there is never Public disclosure of vulnerabilities (another reason why our current state of vulnerabilities identified earlier should be removed. This will become a public document). (source, cause and remediation methods) found on the system which is prohibited and must remain discrete for certified “DMV eyes-only.”

• The Vendor shall ensure that the system has the ability to discover new security vulnerabilities on a second to second basis where the solution vendor must have

Page 79: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 79 of 113

SYSTEM REQUIREMENTS – SECURITY STANDARDS If applicable, this section should include the security standards specific to the agency.

These are over and above the security standards in Section 4.5 which must be included in all IT RFPs. (another reason why our current state of vulnerabilities identified earlier should be removed. This will become a public document). (source, cause and remediation methods) found on the system which is prohibited and must remain discrete for certified “DMV eyes-only.”

• The Vendor shall ensure that the system has the ability to discover new security vulnerabilities on a second to second basis where the solution vendor must have resources to test or know-of every possible vulnerable software configuration in that some vulnerability may be revealed only in very specific setups.

• The Vendor shall be responsible to get patches out in a timely manner to meet the gravitas of the breach and the magnitude of disruption to business continuity the lack of which will cause the DMV to seek remedies from the vendor as in the case of a crash that lasts over 30 minutes to recover or a breach that penetrates the DMV administered “A” and “B” level security wall.

• The Vendor should use available best practices to enforce system Zero-Tolerance functional policy models such as Google, Yahoo and Amazon, where top level industry standards immediately expose any internal or external threats to its infrastructure and integrity of its product offerings.

• The Vendor must incorporate the ability to develop SLAs on the fly with all DMV interfaces that may in the case of breaches be given notice to comply and upgrade or be turned off with consequences.

• The Vendor should adopt a similar practice model such as Google’s Zero-Tolerance policy which is set by a hard 90-day deadline to remediate or turn-off; where other Zero-Tolerance functional models have shorter deadlines; for example, the CERT division at Carnegie Mellon has a 45-day disclosure policy.

• The Vendor should incorporate a case management tool that takes a case-by-case approach to any and all breaches.

• The Vendor must be aware that not all security risks can be managed solely by technology where detection can be radically enhanced using smart cameras or audio recordings as well as digital documentation of any adverse behavior that could be considered a threat, including but not limited to the use of rogue software loaded onto DMV computers (coupons, gambling and morally depraved content).

• The Vendor must be aware of The FBIs Trilogy Information Technology Operations experience and how this functional policy partners with the FBI Enterprise Architecture to enforce their philosophy of zero tolerance security risks, seeking not to manage risk but to avoid it.

• The Vendor must make itself aware that DMVs historically are prime targets for malicious and criminal activities and that the FBI Trilogy Model is in all probability the best practice approach.

IMPLEMENT ZERO INCIDENT SECURITY

• The Vendor must adopt a Zero-incidents system reaction model in addition to Zero-tolerance services that must force a strong responses and indemnity after an event.

• The Vendor must adopt the functional capacity to ensure that preventative frameworks ensure zero incidents making sure there is never an event in the first place.

• The Vendor must adopt in its system some form of sophisticated scanners and listeners to enforce Zero-incident security management that must be able to immediately to recognize high-risk users; internally or externally that might pose an eventual or immediate threat to DMV that be easily operated/managed by DMV, where the Vendor will be responsible to turn-over skill sets and train DMV

Page 80: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 80 of 113

SYSTEM REQUIREMENTS – SECURITY STANDARDS If applicable, this section should include the security standards specific to the agency.

These are over and above the security standards in Section 4.5 which must be included in all IT RFPs. place.

• The Vendor must adopt in its system some form of sophisticated scanners and listeners to enforce Zero-incident security management that must be able to immediately to recognize high-risk users; internally or externally that might pose an eventual or immediate threat to DMV that be easily operated/managed by DMV, where the Vendor will be responsible to turn-over skill sets and train DMV technicians and supply meaningful documentation at the time of end of vendor contract, unless included in a follow-on general maintenance and upgrade agreement.

• The Vendor must ensure that the system has sufficient awareness of erratic or out of the ordinary life factor behavior as well as non-verbal system behavior such as email content, copying files that are confidential, where files are unusually deleted, etc.,; and how to de-escalate such situations if they rear up.

IMPLEMENT CC 2.1 ASSURANCE SCOPE & REQUIREMENTS

• The Vendor must underpin the DMV’s approach to functional assurances by following the Security Assurance Requirements cited in the Common Criteria for Information Technology Security Evaluation (CC 2.1).

• The Vendor must ensure compliance with CC 2.1 which is aligned with International Standard ISO/IEC 15408:1999 and must be adhered to in context of the offering asked for in the narrative, requirements and Reference Architecture (RA) for DMV Security in that the joint holders and governing bodies of CC 2.1 are National Institute of Standards and Technology and the National Security Agency.

The scope of CC 2.1 to be considered for this RFP is: • Assurance requirements of CC 2.1

• A scale for measuring assurance • A criteria for evaluation

Using CC 2.1 as a basis for Security Assurance policies DMV will jointly adopt the CC philosophy with the vendor, in that the threats to security and organizational security policy commitments will be clearly articulated and the proposed security measures be demonstrably sufficient for their intended purpose.

DMV’s requirement to implement CC 2.1 strategy will further the adoption of measures that:

• Reduce the likelihood of vulnerabilities • Increase the ability to exercise control over (i.e. intentionally exploit or

unintentionally trigger) a vulnerability, • Offer remediation of the extents of damages that could occur from a

vulnerability being exercised. • Facilitate the subsequent identification of vulnerabilities

• Elimination, mitigation, and/or notification that a vulnerability has been exploited or triggered

CONTROL AND MONITORING REQUIREMENTS FOR MEASUREABLE AREAS OF FUNCTIONAL

The Vendor must design its system with an understanding of the following weaknesses that DHS describes in its vulnerabilities recap:

• Authentication • Denial of Service

• Buffer Overflow

Page 81: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 81 of 113

SYSTEM REQUIREMENTS – SECURITY STANDARDS If applicable, this section should include the security standards specific to the agency.

These are over and above the security standards in Section 4.5 which must be included in all IT RFPs. MONITORING REQUIREMENTS FOR MEASUREABLE AREAS OF FUNCTIONAL VULNERABILITY

that DHS describes in its vulnerabilities recap:

• Authentication • Denial of Service

• Buffer Overflow • Memory Corruption

• Directory Traversal • Protocol Vulnerability

• Privilege Escalation • Cross Site Scripting

• Remote Code Execution • SQL Injection

• Integer Overflow • Stack Overflow

• Heap Corruption • Use After Free

• Multiple

DHS IT VUNERABILITIES RECAP

DHS NCCIC National Cybersecurity and Communications Integration Center ICS-

CERT Monitor

WEB SERVICE COMPONENTS OF HIGHLY AVAILABLE SECURITY ARCHITECTURE

The Vendor shall follow the recommendations set out in the following Four Web Service Requirements: 1. Transparency: transparent recovery is needed to ensure that users (internal and

external) never experience a loss of a Web presence. 2. Recovery from malicious hacking attacks and malware by enabling frontend

quarantine devices while a backend countermeasure is launched to destroy or at least mitigate the threat.

3. Recovery from system failure: a mechanism that keeps the Agency’s sites running at a minimum in the event of a failure within the Internet Data Center, e.g., hardware or software.

Page 82: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 82 of 113

SYSTEM REQUIREMENTS – SECURITY STANDARDS If applicable, this section should include the security standards specific to the agency.

These are over and above the security standards in Section 4.5 which must be included in all IT RFPs. ARCHITECTURE quarantine devices while a backend countermeasure is launched to destroy or at

least mitigate the threat. 3. Recovery from system failure: a mechanism that keeps the Agency’s sites running

at a minimum in the event of a failure within the Internet Data Center, e.g., hardware or software.

4. Recovery from site failure: keeping the site running in the event of a failure that takes down the entire Internet Data Center, e.g., natural disasters or utility failures.

MICROSOFT COMPONENTS VERSIONS AND SECURITY PATCHES

The Vendor must create an insulation layer to indemnify the intended modernization system from 3rd party security failures due to DMV maintaining old versions of Microsoft Browser technology. See below:

“Microsoft has announced its intention to stop supporting older versions of the Internet Explorer Web browser starting with January 12, 2016. Starting with January 2016, technical support and security updates will no longer be available for Internet Explorer 8.” The Vendor must extend this insulation to all Microsoft DLLs, MS Word and Excel as well as any other MS product in their Office suite or separate to. The Vendor application security and applicability may be limited if DMV cannot support the latest version of IE.

REQUIREMENTS MATRIX If applicable, this section should include a system requirements matrix.

The matrix can be prepared as an Excel spreadsheet or in a table format. There is a sample in the RFP of the type of conditions/descriptions to be met.

In Process: Workbook of 39+ Business Requirement Function Spreadsheets to be inserted upon completion.

Page 83: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 83 of 113

SCOPE OF WORK AND DELIVERABLES

The project should be broken down into the following: Tasks (with a defined Objective), Activities (to meet the objective) and Deliverables (tied to each of the activities)

The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section should mirror the format of the Planning and Administration Section.

Planning and Administration

Objective:

The objective of this task is to ensure that thorough, well thought out and executable planning and project management is dedicated to this project. This section appears to be a cut and paste from something and needs a lot of clean up. If the vendor is required to submit these plans in their RFP response they cannot work in conjunction with DMV. Some of these plans/reports will be after award but the Master and Project plans should be required in the RFP response. These reports/plans should be defined accordingly.

Scope:

The awarded vendor must fulfill 1 – 13 of the required general deliverables:

1). Develop a Master Project Plan; Vendor shall develop and submit a Master Project Plan. This plan will contain fixed deadlines that take into consideration the State Holidays.

2. Develop a Detailed Project Plan; This plan will contain fixed deadlines that take into consideration the State holidays for all requirements in this RFP.

a. Project schedule including tasks, activities, activity duration, sequencing and dependencies;

b. Project work plan for each deliverable, including a work breakdown structure;

c. Completion date of each task;

d. Project milestones;

e. Entrance and exit criteria for specific project milestones; and

f. Project organization including a resource plan defining roles and responsibilities for the awarded vendor, subcontractors (if applicable) and State.

3. Develop a Record of Meeting Attendance; in conjunction with DMV recording all those required persons and/or proxies who attend, plus additional optional attendees, as well as those required who do not attend by default that participate in all project related meetings requested by the State at a location to be determined by the State. Attendance shall be in person for all key project team members. Additional project resources may be via teleconferencing, as mutually agreed to by the project team. These meetings shall follow an agenda mutually developed by the State and the awarded vendor. The awarded vendor shall prepare materials or briefings for these meetings as requested by the State. Minutes will be taken and distributed by State staff within five (5) working days after the meeting. Minutes will be distributed as defined by the communications plan.

The agenda may include, but not be limited to:

a. Review and approval of previous meeting minutes;

Page 84: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 84 of 113

SCOPE OF WORK AND DELIVERABLES The project should be broken down into the following: Tasks (with a defined Objective),

Activities (to meet the objective) and Deliverables (tied to each of the activities) The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section

should mirror the format of the Planning and Administration Section.

b. Contractor project status;

c. State project status;

d. Contract status and issues, including resolutions;

e. Quality assurance status;

f. New action items;

g. Outstanding action items, including resolutions;

h. Setting of next meeting date; and

i. Other business.

4. Provide Semi-monthly Overall Project Status Reports; the Vendor must submit status reports to the State for acceptance. The report is to be delivered to State project management by the third (3rd) working day following the end of each reporting period. For all sub-projects, a weekly project status report must be written and provided by the first (1st) working day following the end of the previous week. The format must be approved by the State prior to issuance of the first semi-monthly project status report. The first semi-monthly report covers the reporting period from the 1st through the 15th of each month; and the second semi-monthly report covers the reporting period from the 16th through the end of the month. The status reports must include, but not be limited to the following:

a. Overall completion status of the project in terms of the State approved project work plan and deliverable schedule;

b. Accomplishments during the period;

c. Problems encountered and proposed/actual resolutions;

d. What is to be accomplished during the next reporting period;

e. Issues that need to be addressed, including contractual;

f. Quality Assurance status;

g. Updated MS Project time line showing percentage completed, tasks assigned, completed and remaining;

h. Identification of schedule slippage and strategy for resolution;

i. Contractor staff assigned and their location/schedule;

j. State resources required for activities during the next time period; and

Page 85: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 85 of 113

SCOPE OF WORK AND DELIVERABLES The project should be broken down into the following: Tasks (with a defined Objective),

Activities (to meet the objective) and Deliverables (tied to each of the activities) The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section

should mirror the format of the Planning and Administration Section.

k. Resource allocation percentages including planned versus actual by project milestone.

5. Develop a Funding Forecast Report (are these intended to be quarterly, annually? This is confusing as it also includes monthly reports. What is the objective of this report?) ; the Vendor must provide funding forecast reports to the State for acceptance. The aim of this report is to formally publish in writing the completion of monthly funding forecasting reports by the third (3rd) working day following the end of each reporting period. The format shall be provided by the State. The funding forecast report shall be approved prior to completion of the monthly funding forecast report. The monthly report covers the reporting period from the 1st through the end of the month. The report is to ensure that funding variances are identified, planned for, corrective action initiated, communicated, and acted upon effectively. The funding forecast report must include, but not be limited to the following:

a. Overall funding status of the sub-project in terms of the State approved project work plan and deliverable schedule;

b. Expended funds during the monthly period;

c. Forecast Funds to be spent for the next project duration;

d. Funding forecast variance;

e. Identification of funding forecast variance, reason for variances and strategy for corrective action;

f. Funding forecast variances (+-) outside of allowed definitions will require an immediate meeting with DMV Project Management Team.

6. Develop a Communication Plan; the Vendor must provide a communication plan to the State for acceptance. This plan must include a comprehensive approach for handling communications with both internal and external audiences. Effective communication is critical to the development of productive relationships with concerned stakeholders. The communication plan must be created for the entire project and all sub-projects and include, but not be limited to: a plan for generation, documentation, storage, transmission and disposal of all project information.

7. Develop a Risk Management Plan; the Vendor must provide a Risk Management Plan to the State for acceptance. This plan will ensure that risks are identified, planned for, analyzed, communicated and acted upon effectively. The risk management plan must be created for the entire project and all sub-projects.

8. Develop a Quality Assurance Plan; the Vendor must provide a Quality Assurance Plan to the State for acceptance. This plan will include workmanship, project schedules and subcontractor(s) activities. The quality assurance plan must be created for the entire project and all sub-projects.

9. Develop a Change Management Plan & Control Procedures; the Vendor must provide Change Management and Control Procedure plans to the State for acceptance. This plan will be used by the vendor and the State in the design specification. The change management plan and control procedures must be provided for the entire project and all sub-projects.

Page 86: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 86 of 113

SCOPE OF WORK AND DELIVERABLES The project should be broken down into the following: Tasks (with a defined Objective),

Activities (to meet the objective) and Deliverables (tied to each of the activities) The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section

should mirror the format of the Planning and Administration Section. provided for the entire project and all sub-projects.

10. Develop a Resource Management Plan; the Vendor must provide a Resource Management Plan to the State for acceptance. This plan is to ensure that all resources are identified, procured, and roles and responsibilities are assigned for all project activities and acted upon effectively. The resource management plan must be created for the entire project and all sub-projects.

11. Develop a Procurement Management Plan; the Vendor must provide a Procurement Management Plan to the State for acceptance. This plan is to ensure all procurement components are identified, procured, and implemented and acted upon effectively. The procurement management plan must be created for the entire project and all sub-projects.

12. Develop a Control Procedures Streamlining Plan; the Vendor must provide a Control Procedures Streamlining Plan to the State for acceptance. This plan will be used by the vendor and the State in the design specification.

13. Develop a Business Continuity and Disaster Recovery Plan; the Vendor must provide a Business Continuity and Disaster Recovery Plan to the State for acceptance. This plan will be used by the vendor and the State in the design specification.

Deliverables:

Vendors must reflect within their proposal and plans their recommended approach to developing the required plans and accomplishing all tasks and activities identified within this RFP.

Project Methodology

Objective:

The objective of this task is to ensure that an efficient well reported project methodology is dedicated to this project.

Scope: The Vendor must describe the project management methodology and processes utilized for:

1. Project integration to ensure that the various elements of the project are properly coordinated;

2. Project scope to ensure that the project includes all the work required and only the work required to complete the project successfully;

3. Time management to ensure timely completion of the project. Include defining activities, estimating activity duration, developing and controlling the project timeline schedule;

4. Management of contractor and/or subcontractor issues and resolution processes;

5. Responding to and covering requested changes in the project time frames;

Page 87: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 87 of 113

SCOPE OF WORK AND DELIVERABLES The project should be broken down into the following: Tasks (with a defined Objective),

Activities (to meet the objective) and Deliverables (tied to each of the activities) The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section

should mirror the format of the Planning and Administration Section.

6. Responding to State generated issues;

7. Cost management plan to ensure that the project is completed within the approved budget. Include resource planning, cost estimating, cost budgeting and cost control;

8. Resource management plan to ensure the most effective use of people involved in the project including subcontractors;

9. Communications management plan to ensure effective information generation, documentation, storage, transmission and disposal of project information; and

10. Risk management plan to ensure that risks are identified, planned for, analyzed, communicated and acted upon effectively.

Deliverables: Vendors must reflect within their proposal and methodologies their recommended approach to scheduling and accomplishing all tasks and activities identified within this RFP.

Project Implementation and Deliverables

Objective: The objective of this task is to ensure that 100% successful project implementation and deliverables are fulfilled and dedicated to this project.

Scope:

Upon BOE contract approval, the successful Vendor will meet with all project committee representatives prior to the start of work activities to discuss project methodology, scheduling and to ensure mutual understanding of the work to be done. When significant findings or recommendations are to be presented or discussions are needed, the meetings will be held at NV Department of Motor Vehicles 555 Wright Way, Carson City, NV 89711

A project kick off meeting will be held with representatives from the State and the contractor after award and prior to work performed. Items to be covered in the kick off meeting will include, but not be limited to:

1. Deliverable review process;

2. Determining format and protocol for project status meetings;

3. Determining format for project status reports;

4. Setting the schedule for meetings between representatives from the State and the contractor to develop the detailed project plan;

5. Defining lines of communication and reporting relationships;

Page 88: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 88 of 113

SCOPE OF WORK AND DELIVERABLES The project should be broken down into the following: Tasks (with a defined Objective),

Activities (to meet the objective) and Deliverables (tied to each of the activities) The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section

should mirror the format of the Planning and Administration Section.

6. Reviewing the project mission;

7. Pinpointing high-risk or problem areas; and

8. Issue resolution process.

The vendor will meet with the Department's business and technical personnel within thirty (30) days of contract award

The Vendor will meet and coordinate with the Department to complete a communication plan within thirty (30) days of contract award

Deliverables: Vendors must reflect within their proposal the implementation and subsequent deliverables as to their recommended approach to scheduling and accomplishing all tasks and activities identified within this RFP.

Project Schedule

Objective: The objective of this task is to ensure that a manageable agile project schedule is dedicated to this project.

Scope:

The Vendor shall work with the DMV to develop all initial master project plan schedules that will include: project initiation, time allotments for planning of all components, development of sub-project plans. The project initiation and planning will encompass all requirements of this RFP.

The DMV must approve the master project plan. Upon approval, the vendor shall work with the DMV to develop the sub-project plans to include items such as, but not limited to: Time allotments for procurement, infrastructure, purchasing and installation, business requirements, business systems design, technical design, application development, training, extensive internal and external testing, implementation, physical build-out requirements, customer notification, forms designs, policy and procedure updates, system documentation, etc.

The Vendor will meet with the Department for a formal sign off.

Deliverables:

Vendors must reflect within their proposal the implementation and subsequent deliverables as to their recommended approach to scheduling and accomplishing all tasks and activities identified within this RFP.

Technical Requirements

Objective:

The objective of this task is to ensure that the Vendor has the sound technical knowledge and background to replace and transform the current legacy environment with SOA and MDM environments that are seamlessly integrated and adhere to the Zero-tolerance Master Security Model, thus vastly improving business performance by providing State users with new and expanded capabilities that reflect, and are in keeping with, industry standards and best practices.

Page 89: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 89 of 113

SCOPE OF WORK AND DELIVERABLES The project should be broken down into the following: Tasks (with a defined Objective),

Activities (to meet the objective) and Deliverables (tied to each of the activities) The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section

should mirror the format of the Planning and Administration Section. integrated and adhere to the Zero-tolerance Master Security Model, thus vastly improving business performance by providing State users with new and expanded capabilities that reflect, and are in keeping with, industry standards and best practices.

Scope:

All proposed software used in the design, development, testing and implementation of the deliverables outlined in this RFP must be approved by the State.

If the application software is not public domain, the awarded Vendor must provide a licensing strategy.

The Vendor will determine high-level technical requirements and system specifications that shall achieve the business requirements outlined in the Business Requirement Document based on the Department approved project timeline.

The Vendor is required to submit the following project deliverables for all requirements in this RFP. These deliverables must be created for the master plan and each sub-project plan These deliverables must be approved by the Department's Program Manager and project sponsor:

1. The Vendor will provide input and work with the Department as required on the Business Requirement Document

2. The Vendor will meet with the Department's business and technical personnel, based on the project timeline, after BOE contract approval to establish and finalize the Business Requirement Document. The Business Requirement Documents shall contain a list of business requirements that shall be used as the basis for each implementation phase of the project.

3. The Vendor will meet with Department's business and technical personnel based on the project timeline, after contract award to define management information reporting requirements.

4. The Vendor will work with the DMV to create a communication plan requirement based on the project timeline after contract award for all levels of the organization. The communication plan must include both business and technical information. These requirements must be included as part of the Business Requirement Document

5. The Vendor will work with the DMV to determine high-level technical requirements and system specifications that shall achieve the business requirements outlined in the Business Requirement Document based on the approved project timeline.

Deliverables:

Vendors must reflect within their proposal the requirements and subsequent deliverables as to their recommended approach to scheduling and accomplishing all tasks and activities identified within this RFP.

Technical Design Document

Page 90: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 90 of 113

SCOPE OF WORK AND DELIVERABLES The project should be broken down into the following: Tasks (with a defined Objective),

Activities (to meet the objective) and Deliverables (tied to each of the activities) The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section

should mirror the format of the Planning and Administration Section.

Objective: The objective of this task is to ensure that the Vendor produces a sound technical design document to act as a sufficiently detailed road-map to replace and transform the current legacy environment with SOA and MDM environments that are seamlessly integrated and adhere to the Zero-tolerance Master Security Model, thus vastly improving business performance by providing State users with new and expanded capabilities that reflect, and are in keeping with, industry standards and best practices with proven high degree of confidentiality, integrity, reliability and availability, which should, at a minimum provide 99.9% availability 24/7 to all users (what if they do not perform to this level?)

Scope: The Vendor will work with the DMV to develop within the approved project timeline after contract award, a Technical Design Document that shall provide detailed specifications for the chosen technical solution, which include but are not limited to system architecture, message layouts, transaction and system security, and databases. A detailed technical process flow, associated roles and responsibilities and new processes and procedures must also be included as part of the Technical Design Document.

The technical design document will include but not be limited to:

1. Technical requirements that identify attributes, capabilities, characteristics, or qualities of a system

2. Architecture/Design – Overview of software and hardware. Includes design principles to be used in design of system components to include:

a. Software

b. System Hardware

c. Data Management

d. Networking

e. Zero Tolerant Security

f. Control Processes – change control, build and deploy, configuration management, etc.

3. Database documentation to include:

a. Data Dictionary

b. Entity Relationship diagram (showing DB relationships)

c. List of Database objects to include Tables, Stored Procedures, Views, and User Defined Functions along with descriptions and usage

d. Encryption Levels (Mandatory) to be compatible with State of Nevada standards and additionally with current NIST, and HIPAA standards.

Page 91: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 91 of 113

SCOPE OF WORK AND DELIVERABLES The project should be broken down into the following: Tasks (with a defined Objective),

Activities (to meet the objective) and Deliverables (tied to each of the activities) The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section

should mirror the format of the Planning and Administration Section.

e. Detailed explanation of the implemented security model.

4. Technical – documentation of code, algorithms, interfaces, and API’s.

5. End User – Manuals for the end user, system administrators and support staff

6. The Vendor will work with the DMV to provide the Department with a 60 day advance notice of changes to be implemented

7. The Vendor will provide the Department with the changes to be put into the test environments at least (hours, days, etc.) prior to release to production.

Deliverables: Vendors must reflect within their proposal the design and subsequent deliverables as to their recommended approach to scheduling and accomplishing all tasks and activities identified within this RFP.

Comprehensive Training Plan

Objective: The objective of this task is to ensure that the Vendor produces a comprehensive training plan to sufficiently train and/or retrain the entire DMV workforce time-to-market readiness, thus vastly improving business performance by providing State users with new and expanded capabilities that reflect, and are in keeping with, industry standards and best practices with proven high degree of confidentiality, integrity, reliability and availability, which should, at a minimum provide 99.9% availability 24/7 to all users.

Scope: The Vendor will submit Comprehensive Training Plans as follows:

1. The Vendor will work with the DMV to create and execute a comprehensive training plan based on the approved project timeline that includes, but is not limited to:

a. DMV transactions and procedures.

b. Overview of computer system and data storage.

c. Interpreting information on vehicle records.

d. Correct usage of codes and proper format.

e. Information and system security functions.

f. Problem identification and resolution.

g. Use of reference materials.

Page 92: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 92 of 113

SCOPE OF WORK AND DELIVERABLES The project should be broken down into the following: Tasks (with a defined Objective),

Activities (to meet the objective) and Deliverables (tied to each of the activities) The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section

should mirror the format of the Planning and Administration Section.

2. The Vendor will work with the DMV to arrange training for Department employees, at appropriate intervals determined by the vendor and the Department, as needed due to employee turnover or changes in system design or procedures, or any other reason deemed by the Department to require additional training.

Deliverables:

Vendors must reflect within their proposal the plan and subsequent deliverables as to their recommended approach to scheduling and accomplishing all tasks and activities identified within this RFP.

Comprehensive Test Plan

Objective: The objective of this task is to ensure that the Vendor produces a sound and executable comprehensive test plan, to initially run tests parallel with the current legacy environment, as well as performing standalone unit, integrated and end-to-end security and end-to-end performance testing in SOA and MDM environments on the intended system as it is rolled out. The comprehensive test plan must also bear out the integrity of seamlessly implementing tests to adhere to the Zero-tolerance Master Security Model, thus vastly improving the security and business performance by providing State users with new and expanded capabilities that reflect, and are in keeping with, industry standards and best practices with proven high degree of confidentiality, integrity, reliability and availability, which should, at a minimum provide 99.9% availability 24/7 to all users.

Scope: The Vendor will submit Comprehensive Test Plans as follows:

1. The Vendor will work with the DMV to develop a comprehensive set of test conditions based on the approved project timeline for all developed applications, system components, and security components.

2. The Vendor will develop and execute a comprehensive test plan based on the approved project timeline, after BOE contract approval that includes, but is not limited to:

a. System Connectivity: Ensure that all system components are installed and communicating properly.

b. Business Functionality: Ensure that the application and system components work together to achieve the desired business requirements as outlined in the Business Requirement Document.

c. Management Expectation Testing: Ensure that the Department's management team indicates that the application and information reports meet their expectations. Track any problem incidents that are found during all phases of testing, assess what corrective action is needed and take corrective action; based on a timeline manner

Deliverables:

Vendors must reflect within their proposal the plan and subsequent deliverables as to their recommended approach to scheduling and accomplishing all tasks and activities identified within this RFP.

Page 93: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 93 of 113

SCOPE OF WORK AND DELIVERABLES The project should be broken down into the following: Tasks (with a defined Objective),

Activities (to meet the objective) and Deliverables (tied to each of the activities) The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section

should mirror the format of the Planning and Administration Section.

Implementation Plan

Objective:

The objective of this task is to ensure that the Vendor produces a sound and executable implementation plan, to ensure the seamless dropping of code, firing off actionable interfaces, managing metadata, proving the UI/USB can handle the predicted traffic, ensuring the apps and their reference DBs talk to each other, ensuring that the OS can manage a collaborative farm and that the network can adapt and carry the broker load and still implement the security measures in the Zero-tolerance Master Security Model, thus vastly improving the security and business performance by providing State users with new and expanded capabilities that reflect, and are in keeping with, industry standards and best practices with proven high degree of confidentiality, integrity, reliability and availability, which should, at a minimum provide 99.9% availability 24/7 to all users.

Scope: Note: Rather than continuing to mention “after BOE approval” in each section, make the statement in the overview in Section 1 that the project is contingent upon legislative and BOE approval.

The Vendor will submit Implementation Plans.

1. The Vendor will work with the DMV to develop and execute implementation plans based on the approved project timelines, that includes, but is not limited to, a migration plan, responsibility matrixes, cutover plans, incident response plans, and back out plans.

The Vendor will submit Post-Implementation Plans.

1. The Vendor will work with the DMV to develop comprehensive post-implementation plans based on the approved project timelines, for all developed applications, system components, and security components.

2. The Vendor will work with the DMV to identify the problem reporting system to track problem reports and resolutions.

3. The Vendor will work with the DMV to provide a written evaluation after three months of implementing the specific Sub-Project. The evaluation should include opportunities for improvement. This will include an after action review.

Deliverables:

Vendors must reflect within their proposal the plan and subsequent deliverables as to their recommended approach to scheduling and accomplishing all tasks and activities identified within this RFP.

Project Management Tools

Objective:

The objective of this task is to ensure that the Vendor utilizes and optimizes project management tools to raise the bar on rolling out the new system as expediently and efficiently as possible thus vastly improving the security and business performance by providing State users with new and expanded capabilities that reflect, and are in keeping with, industry standards and best practices with proven high degree of confidentiality, integrity, reliability and availability, which should, at a minimum provide 99.9% availability 24/7 to all users.

Page 94: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 94 of 113

SCOPE OF WORK AND DELIVERABLES The project should be broken down into the following: Tasks (with a defined Objective),

Activities (to meet the objective) and Deliverables (tied to each of the activities) The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section

should mirror the format of the Planning and Administration Section. confidentiality, integrity, reliability and availability, which should, at a minimum provide 99.9% availability 24/7 to all users.

Scope: The Vendor will submit required materials for Project Management. We should distinguish the Program Manager from the Project Managers where appropriate.

1. The Vendor will be responsible for working with the Department’s Program Manager for preparing materials for Project Manager meetings, and conference calls, conducted as required by the Department.

The Vendor’s project manager will be present for all Department meetings and/or conference calls.

The Vendor will work with the DMV to provide a meeting agenda to the Department’s Program Manager at least 24 hours prior to any meeting.

2. A sub-project status report should be prepared weekly, or at the request of the Department’s Program Manager. The report should contain activities, problems, issues, risks, and recommendations for presentation to the Project Manager(s).

a) The Vendor will work with the Department’s Program Manager to develop formal issue papers to assist with the resolution of issues that cannot be resolved by the project management team and present those issue papers to the Department. Issued papers should define the issue, evaluate at least two alternative solutions, and conclude with a recommendation. The vendor will then implement the recommendation if approved by the Department.

b) The Vendor will work with the Department’s Project Manager(s) to document in writing all meetings and conference calls related to the DMV system. This documentation will be submitted to the Department within three business days. This task should be assigned to the BPA’s and/or Project Coordinator positions.

3. A funding forecast sub-project status report should be prepared monthly, or at the request of the Department's Project Manager/s. The report should contain funding activities, forecasting, variances, recommendations/corrective actions, and should be presented to the Project Manager/s.

a) The Vendor will work with the Department's Program Manager to develop formal forecast variance issue papers to assist with the correction action that cannot be resolved by the project management team and present those corrective action papers to the Department. Corrective action papers should define the funding variance, evaluate at least two corrective action alternative solutions, and conclude with a recommendation. The vendor will work the DMV to implement the recommendation if approved by the Department.

b) The Vendor will work with the Department's Project Manager/s to document in writing all meetings and conference calls related to the DMV system. This documentation will be submitted to the Department within three business days. Again, this is a function of BPA’s/Project Coordinators.

Deliverables: Vendors must reflect within their proposal the tools and subsequent deliverables as to their recommended approach to scheduling and accomplishing all tasks and activities identified within this RFP.

Page 95: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 95 of 113

SCOPE OF WORK AND DELIVERABLES The project should be broken down into the following: Tasks (with a defined Objective),

Activities (to meet the objective) and Deliverables (tied to each of the activities) The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section

should mirror the format of the Planning and Administration Section.

Policy Manuals

Objective:

The objective of this task is to ensure that the Vendor produces intuitive and instructional policy manuals that allow the Vendor and DMV to collaborate in enriching the governance quality thus vastly improving the security and business performance by providing State users with new and expanded capabilities that reflect, and are in keeping with, industry standards and best practices with proven high degree of confidentiality, integrity, reliability and availability, which should, at a minimum provide 99.9% availability 24/7 to all users.

Scope:

The Vendor will work with the DMV to develop and provide detailed Department-approved policy manuals based on the approved project timeline, , outlining all operating guidelines for all users, including security procedures, properly executed paperwork, and training requirements. The vendor will reproduce and distribute these manuals to the Department.

The Vendor will submit the following transactional and financial reports:

1. The Vendor will submit daily, monthly and yearly reports on transactions processed (is this intended during the development phase? Not sure of the relevance here). The reports must include summaries, transaction type, and errors. Individual summaries for each service provider must also be included (do not see any relevance for this requirement). The Department may require additional report information to be determined at the Department's discretion.

Deliverables:

Vendors must reflect within their proposal the manuals and subsequent deliverables as to their recommended approach to scheduling and accomplishing all tasks and activities identified within this RFP.

Customer Service Requirements

Objective:

The objective of this task is to ensure that the Vendor produces clear instructional customer service requirements that allow the DMV to enrich and educate the customers of the Nevada DMV thus vastly improving the security and business performance by providing State users with new and expanded capabilities that reflect, and are in keeping with, industry standards and best practices with proven high degree of confidentiality, integrity, reliability and availability, which should, at a minimum provide 99.9% availability 24/7 to all users.

Scope: The Vendor must provide a DMV US-based Help Desk or online help function to assist NV DMV with staff issues using the system for the duration of the project; Is this intended beyond project implementation or will we convert to our Application Support Group?

The Vendor shall provide DMV US-based Help Desk service. The help desk will be available during DMV business hours, Pacific Standard Time, Monday through Friday. (or further define based on need)

Page 96: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 96 of 113

SCOPE OF WORK AND DELIVERABLES The project should be broken down into the following: Tasks (with a defined Objective),

Activities (to meet the objective) and Deliverables (tied to each of the activities) The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section

should mirror the format of the Planning and Administration Section.

The help desk shall provide assistance to DMV and DMV Project Team with discrepancy resolution, system and processing problems and training issues.

The Vendor will work directly with the Department's appropriate staff when assistance is needed in resolving any help desk issues.

Deliverables: Vendors must reflect within their proposal the requirements and subsequent deliverables as to their recommended approach to scheduling and accomplishing all tasks and activities identified within this RFP.

Audit Requirements

Objective:

The objective of this task is to ensure that the Vendor produces clear audit requirements that allow the DMV to enrich and educate the internal business processes of the Nevada DMV thus vastly improving the security and business performance by providing State users with new and expanded capabilities that reflect, and are in keeping with industry standards and best practices with proven high degree of confidentiality, integrity, reliability and availability, which should, at a minimum provide 99.9% availability 24/7 to all users. (This is consistently used but question what if the system is not available at this level?)

Scope: 1). The Vendor will provide, in accordance with the Statement of Standards for Attestation Engagement (SSAE) 16 WHERE APPLICABLE:

SOC 1 Policy Packets on Reports on Controls at a Service Organization and SSAE 16

"Report on management's description of a service organization's system and the suitability of the design of controls".

SOC 2 - Policy Packets on AICPA if your organization has a true relationship and/or nexus with ICFR.

"Report on management's description of a service organization's system and the suitability of the design and operating effectiveness of controls".

SOC 3 - Reports and Trust Service Principles International Standards for Assurance Engagements (ISAE) No. 3402 and Service Organization Control (SOC) reporting.

The Service Organization Controls, SOC 1, 2 & 3, enhance the audit of vendors which provides services that will affect security, availability, and processing integrity of the DMV system that processes users' data and maintaining confidentiality and privacy of information processed by the system.

2). Sarbanes-Oxley Act (SOX) Sections 302 & 404 “Equivalent Traceability” to offset FRAUD

Page 97: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 97 of 113

SCOPE OF WORK AND DELIVERABLES The project should be broken down into the following: Tasks (with a defined Objective),

Activities (to meet the objective) and Deliverables (tied to each of the activities) The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section

should mirror the format of the Planning and Administration Section.

3). American Institute of Certified Public Accountants (AICPA) a). Assurance Services Executive Committee, June 2011, Audit Data Standards and Apps

b). Assurance Services Executive Committee’s Emerging Assurance Technologies Task Force c). Continuous Audit Monograph (CICA/AICPA 1999)

d). Embedded Audit Module (EAM)

4). CIS – Center for Internet Security

5). ISSA – Information Systems Security Association Communication Requirements

6). ITPI – IT Process Institute

7). CMU/SEI – Carnegie-Mellon University, Software Engineering Institute

8). NACD – National Association of Corporate Directors

9). SANS Institute

10). Six Sigma (Black Belt)

Deliverables:

Vendors must reflect within their proposal the requirements and subsequent deliverables as to their recommended approach to scheduling and accomplishing all tasks and activities identified within this RFP.

Communication Requirements

Objective: The objective of this task is to ensure that the Vendor produces clear instructional communications requirements that allow the DMV to enrich communications within the Nevada DMV as well as improving the outreach of all services to customers on the web, mobile and kiosks, thus vastly improving the security and business performance by providing State users with new and expanded capabilities that reflect, and are in keeping with, industry standards and best practices with proven high degree of confidentiality, integrity, reliability and availability, which should, at a minimum provide 99.9% availability 24/7 to all users.

Scope:

The Vendor will take all steps necessary to facilitate interactive and productive communications with the Department

The Vendor will notify the Department when an employee, contractor or sub-contractor no longer has a contract with the vendor.

The Vendor shall provide and maintain a list of the names, mailing address, telephone number, and email address of the contact person for each employee, contractor or sub-contractor using the DMV system. Using Sharepoint?

Page 98: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 98 of 113

SCOPE OF WORK AND DELIVERABLES The project should be broken down into the following: Tasks (with a defined Objective),

Activities (to meet the objective) and Deliverables (tied to each of the activities) The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section

should mirror the format of the Planning and Administration Section. Sharepoint?

The Vendor shall work with the DMV for all contractors, or sub-contract changes, updates, made for the duration of the contract.

Deliverables: Vendors must reflect within their proposal the requirements and subsequent deliverables as to their recommended approach to scheduling and accomplishing all tasks and activities identified within this RFP.

Other Requirements

Objective:

The objective of this task is to ensure that the Vendor produces and fulfills, but not necessarily limited to, the other requirements below that will subsequently enrich efficiency and control within the Nevada DMV, thus vastly improving the security and business performance by providing State users with new and expanded capabilities that reflect, and are in keeping with, industry standards and best practices with proven high degree of confidentiality, integrity, reliability and availability, which should, at a minimum provide 99.9% availability 24/7 to all users. Here this is again!

Scope: The service providers will work directly with the Vendor and not directly with the Department to resolve issues.

The Vendor will maintain current and permanent personnel records for its employees, contractors and sub-contractors involved with the DMV system.

The Vendor will ensure that all Personnel records will be made available to the Department and authorized investigators upon request.

The Vendor will cooperate with any audit and investigation initiated by the Department.

The Vendor will obtain and provide background checks and clearances ,and bond all persons involved in the DMV system. I believe State Purchasing takes care of this under the MSA contracts. WSe may want to provide more details on this requirement.

The Department reserves the right to make unannounced visits to observe and inspect operations. The System Mod staff will be housed at our facility? Not sure we need to reserve the right to inspect, but let them know we will.

The Vendor will provide issue/resolution historical and real-time data querying reporting systems and they must be easily and readily downloadable in a format that is compatible with multiple Microsoft Office products and approved by the DMV.

The issue/resolution system Vendor will permit NV DMV to create and manipulate real-time ad-hoc queries and subsequent reports at any time during normal business hours, without affecting the system’s performance.

Page 99: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 99 of 113

SCOPE OF WORK AND DELIVERABLES The project should be broken down into the following: Tasks (with a defined Objective),

Activities (to meet the objective) and Deliverables (tied to each of the activities) The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section

should mirror the format of the Planning and Administration Section. and subsequent reports at any time during normal business hours, without affecting the system’s performance.

The Vendor will provide an escalation procedure establishing service level agreements to meet the Department’s system issue/resolution timeline.

Deliverables:

Vendors must reflect within their proposal the requirements and subsequent deliverables as to their recommended approach to scheduling and accomplishing all tasks and activities identified within this RFP.

Deliverables Submission

Objective: The objective of this section is to ensure Vendor is knowledgeable about the Deliverable Submission process and DMV State expectations.

Scope:

1). Prior to development and submission of each contract deliverable, a summary document containing a description of the format and content of each deliverable will be delivered to the State Program Manager for review and approval.

The summary document must contain, at a minimum, the following:

A. Cover letter; B. Table of Contents with a brief description of the content of each section;

C. Anticipated number of pages; and D. Identification of appendices/exhibits.

2). The summary document must contain an approval/rejection section that can be completed by the State. The summary document will be returned to the contractor within a mutually agreed upon time frame.

3). Deliverables must be developed by the contractor according to the approved format and content of the summary document for each specific deliverable.

4). At a mutually agreed to meeting, on or before the time of delivery to the State, the contractor must provide a walkthrough of each deliverable.

5). Deliverables must be submitted no later than 5:00 PM, per the approved contract deliverable schedule and must be accompanied by a deliverable sign-off form (refer to Attachment G) with the appropriate sections completed by the contractor.

Deliverables Review

General:

Page 100: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 100 of 113

SCOPE OF WORK AND DELIVERABLES The project should be broken down into the following: Tasks (with a defined Objective),

Activities (to meet the objective) and Deliverables (tied to each of the activities) The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section

should mirror the format of the Planning and Administration Section.

A. The State’s review time begins on the next working day following receipt of the deliverable.

B. The State’s review time will be determined by the approved and accepted detailed project plan and the approved contract.

C. The State has up to five (5) working days to determine if a deliverable is complete and ready for review. Unless otherwise negotiated, this is part of the State’s review time.

D. Any subsequent deliverable dependent upon the State’s acceptance of a prior deliverable will not be accepted for review until all issues related to the previous deliverable have been resolved.

E. Deliverables determined to be incomplete and/or unacceptable for review will be rejected, not considered delivered and returned to the contractor.

F. After review of a deliverable, the State will return to the contractor the project deliverable sign-off form with the deliverable submission and review history section completed.

Accepted:

A. If the deliverable is accepted, the original deliverable sign-off form signed by the appropriate State representatives will be returned to the contractor.

B. Once the contractor receives the original deliverable sign-off form, the State can then be invoiced for the deliverable (refer to Section ?????????).

Comments/Revisions Requested by the State:

If the State has comments and/or revisions to a deliverable, the following will be provided to the contractor:

A. The original deliverable sign-off form with an updated entry to the deliverable submission and review history section.

B. Attached to the deliverable sign-off form will be a detailed explanation of the revisions to be made and/or a marked up copy of the deliverable.

C. The State’s first review and return with comments will be completed within the times specified in the contract.

D. The contractor will have five (5) working days, unless otherwise mutually agreed to, for review, acceptance and/or rejection of the State’s comments.

E. A meeting to resolve outstanding issues must be completed within three (3) working days after completion of the contractor’s review or a documented mutually agreed upon time frame.

F. Agreements made during meetings to resolve issues must be documented separately.

G. Once an agreement is reached regarding changes, the contractor must incorporate them into the deliverable for resubmission to the State.

Page 101: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 101 of 113

SCOPE OF WORK AND DELIVERABLES The project should be broken down into the following: Tasks (with a defined Objective),

Activities (to meet the objective) and Deliverables (tied to each of the activities) The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section

should mirror the format of the Planning and Administration Section. deliverable for resubmission to the State.

H. All changes must be easily identifiable by the State.

I. Resubmission of the deliverable must occur within five (5) working days or a mutually agreed upon documented time frame of the resolution of any outstanding issues.

J. The resubmitted deliverable must be accompanied by the original deliverable sign-off form.

K. This review process continues until all issues have been resolved within a documented mutually agreed upon time frame.

L. During the re-review process, the State may only comment on the original exceptions noted.

M. All other items not originally commented on are considered to be accepted by the State.

N. Once all revisions have been accepted, the original deliverable sign-off form signed by the appropriate State representatives will be returned to the contractor.

O. The contractor must provide one (1) updated and complete master paper copy of each deliverable after approval and acceptance by the State.

P. Once the contractor receives the original deliverable sign-off form, the State can then be invoiced for the deliverable (refer to Section ????????).

Rejected, Not Considered Delivered:

If the State considers a deliverable not ready for review, the following will be returned to the contractor:

A. The original deliverable sign-off form with an updated entry to the deliverable submission and review history section.

B. The original deliverable and all copies with a written explanation as to why the deliverable is being rejected, not considered delivered.

C. The contractor will have five (5) working days, unless otherwise mutually agreed to, for review, acceptance and/or rejection of the State’s comments.

D. A meeting to discuss the State’s position regarding the rejection of the deliverable must be completed within three (3) working days after completion of the contractor’s review or a documented mutually agreed upon time frame.

E. Resubmission of the deliverable must occur within the documented mutually agreed upon time frame.

F. The resubmitted deliverable must be accompanied by the original deliverable sign-off form.

G. Upon resubmission of the completed deliverable, the State will follow the steps outlined in Section ???????, Accepted, or Section ????????, Comments/Revisions Requested by the State.

Page 102: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 102 of 113

SCOPE OF WORK AND DELIVERABLES The project should be broken down into the following: Tasks (with a defined Objective),

Activities (to meet the objective) and Deliverables (tied to each of the activities) The first task should always be Planning and Administration and the balance of tasks in the Scope of Work Section

should mirror the format of the Planning and Administration Section. ???????, Accepted, or Section ????????, Comments/Revisions Requested by the State.

FINANCIAL STABILITY

Please check what information you would like the evaluation committee to use when evaluating each vendor’s financial stability.

Section 6.1.11.3 – Profit and Loss Statements and Balance Statements? Yes: X No:

Amy McKinney, Administrative Services Division Administrator

Dun and Bradstreet Report on successful vendor only?? Yes: X No:

BUSINESS REFERENCES Review the questions in the Business Reference Section and modify as applicable.

Do you want more than five (5) business references? Yes: No: X If so, how many do you want? 5 How many years of experience do you want them to reference?

Minimum of 3 years with a government agency and 5 years in system integration

Review the reference questionnaire embedded here and provide any additional information, comments or specific questions that should be included in the questionnaire.

DMV modifications in red

VENDOR STAFF SKILLS AND EXPERIENCE REQUIRED Vendors must include resumes for key personnel to be responsible

for performance of any contract resulting from the RFP. Review the qualifications as identified in this section of the RFP template and provide modifications as applicable.

Page 103: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 103 of 113

VENDOR STAFF SKILLS AND EXPERIENCE REQUIRED Vendors must include resumes for key personnel to be responsible

for performance of any contract resulting from the RFP. Review the qualifications as identified in this section of the RFP template and provide modifications as applicable.

Project Manager? Yes: X No: Qualifications for Project Manager: Technical Lead? Yes: X No: Qualifications for Technical Lead: Implementation Lead? Yes: X No: Qualifications for Implementation Lead: Individual Team Members? Yes: X No: Qualifications for Individual Team Members: Other types of vendor resources? Yes: X No: If yes, identify the resource and qualification requirements:

VENDOR STAFF RESUMES Review the vendor staff resume format and provide any additions and/or deletions to be made here.

DMV Changes - Added a section titled “Additional Experience Summary”

IT PROCESS SECTIONS

The following sections are part of the Capability Maturity Model (CMM) process for IT projects. Review the sections in the RFP template and determine which sections are applicable for

the type of IT project identified in the RFP.

Page 104: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 104 of 113

IT PROCESS SECTIONS The following sections are part of the Capability Maturity Model (CMM) process for IT projects.

Review the sections in the RFP template and determine which sections are applicable for the type of IT project identified in the RFP.

Project Management? Yes: X No:

Quality Assurance? Yes: X No:

Metrics Management? Yes: X No:

Design and Development Processes? Yes: X No:

Configuration Management? Yes: X No:

Peer Review Management? Yes: X No:

COST SCHEDULE How do you want the vendor to submit their proposed cost/pricing?

There is an Excel spreadsheet embedded in the RFP template that allows vendors to submit cost/pricing in the same format in order to facilitate a good cost comparison.

The schedule should be modified once all of the tasks and deliverables have been determined in the scope of work section.

Review the embedded cost schedule and provide any additional information, comments or specific schedules that should be included.

DMV Updated General Cost tab to reflect Work Scope and Deliverables section.

Do you require the following schedules to be included? Development and Data Conversion Environments? Yes: X No: Integration, System Test and UAT Environments? Yes: X No: Training Environment? Yes: X No: Production Environment? Yes: X No: Annual Product Licensing and Maintenance Schedule? Yes: X No:

FINANCIAL – HOLD BACKS

Do you want hold backs? Yes: X No: If so, what percentage? 15%

WRITTEN QUESTIONS AND ANSWERS

Do you want to allow for more than one (1) question and answer period? Note: More than one (1) question and answer period will add additional time to the RFP process.

Yes: No: X

Page 105: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 105 of 113

REFERENCE LIBRARY

Will there be a reference library? Yes: X No:

DMV RFP links: AAMVA http://www.aamva.org/ ASTM http://www.astm.org/ CDLIS http://www.aamva.org/CDLIS/ CFR http://www.gpo.gov/fdsys/browse/collectionCfr.action?collectionCode=CFR CSTIMS http://www.aamva.org/CSTIMS/ CVISN http://www.fmcsa.dot.gov/information-systems/cvisn/core-cvisn EPA http://www.epa.gov/ FMCSA http://www.fmcsa.dot.gov/ IFTA http://www.iftach.org/ IRP http://www.irponline.org/ NAC http://search.leg.state.nv.us/NAC/NAC.html NRS http://search.leg.state.nv.us/NRS/NRS.html PDPS http://www.aamva.org/PDPS/ PRISM http://www.fmcsa.dot.gov/information-systems/prism/performance-and-registration-information-systems-management-prism SAFER http://www.safer.fmcsa.dot.gov/ SAM http://budget.nv.gov/uploadedFiles/budgetnvgov/content/Documents/State%20Administrative%20Manual.pdf SSOLV http://www.aamva.org/SSOLV/

TERMS AND CONDITIONS - CONTRACT Review the terms and conditions and identify by section number any that may not apply to the project/scope of work.

No DMV changes at this time.

Page 106: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 106 of 113

TERMS AND CONDITIONS - PROJECT Review the terms and conditions and identify by section number any that may not apply to the project/scope of work.

DMV changes: Modify Section 14.3.4 Contractor Space: 14.3.4.2 Communication lines, computers, workstations hardware/software and access to printers will be provided by the DMV. 14.3.4.4 & 14.3.4.5 Not Applicable 14.3.4.6 The State will provide space for up to 20 contractor personnel. Contractor personnel will be co-located with a DMV team assigned to the project.

AGENCY SPECIFIC TERMS AND CONDITIONS Are there any agency specific terms and conditions that need to be included in the RFP? If so, please provide them here.

You may want to restate here that the project award is contingent upon Legislative funding and Board of Examiners contract approval. No DMV Specific Terms or Conditions at this time.

GENERAL INFORMATION/COMMENTS Provide any additional information/comments that should be included in the RFP.

Reference applicable RFP section where information should be included.

No DMV Comments at this time.

AGENCY ATTACHMENTS Does your agency have any specific attachments that should be included within the RFP?

If so, please identify them below and attach them when submitting the RFP Development Form to Purchasing. No Agency Attachments at this time. DMV anticipates having several attachments and/or appendices.

Page 107: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 107 of 113

RFP MAILING AND EVALUATION INFORMATION INSTRUCTIONS

Complete the following tables for mailing list development, evaluation committee member information and evaluation criteria and weights. PROVIDE THE SERVICE CLASSIFICATIONS TO BE USED FOR DISTRIBUTION TO VENDORS

The Service Level Classifications can be found by opening the following document:

29D 29G 29H

MAILING LIST DEVELOPMENT Identify entities who should receive direct notification of the RFP’s release, include the following information

Company Name Contact Name Email Address Phone Number International Registration Plan (IRP)

Robin Murphy [email protected]

703. 963.1286

International Fuel Tax Administration (IFTA)

Lonette Turner [email protected]

480. 839.4382

American Trucking Association (ATA)

Bob Pitcher

[email protected] (703) 838-7939

American Association of Motor Vehicle Administrators

Sheila Prior

[email protected]

(480) 275-4584

Federal Motor Carrier Safety Administration

William Bensmiller [email protected] (775) 687-5335

IBM Software Group Software Client Architect

Tom Campbell [email protected] (801) 791-7665

IBM Mike Vranes [email protected] 801 328 6927 NebuLogic Technologies, LLC. USA.

Nivas Nallanthi [email protected] 972-335-0699

NebuLogic Technologies, LLC.

Hosna Keyhan [email protected] 972.335.0699

Oracle Corporation

Desi Lynn Davis

[email protected] 949.623.9491

Sirius Computer Solutions David G. Russell david,[email protected] 801.964.4923 Unisys Melissa Jones [email protected] (215) 274-1053 Deloitte Rakesh Duttagupta [email protected] 916 288 3977 Software AG Mary Lalouch [email protected] 916.241.9389

Page 108: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 108 of 113

MAILING LIST DEVELOPMENT Identify entities who should receive direct notification of the RFP’s release, include the following information

Salesforce 3250 Barberry Lane Sacramento CA 95864

Steven Galvez 916.642.5949

SAFRAN MorphoTrust USA

David Growe [email protected]

801.938.9959

Dell Inc. Jeff Cochran [email protected] 949.363.2983 Dell Inc. Bob Irby [email protected] 415.233.1965 CenturyLink Cheryl L.Zittle [email protected] 775.386.8189 CenturyLink Peter Zeeb [email protected] FAST Enterprises Mary Kurkjian [email protected] 617.285.0628 FAST Enterprises Ben Goodman [email protected] 406.396.3482 FAST Enterprises David Alderson [email protected] Celtic Systems Joe McCormick [email protected] 480.682.3791 Tech Mahindra Aman Sethi [email protected] 847.275.5791 Tech Mahindra Satish Kumar [email protected] 571.242.3897 Deloitte Consulting LLP Debasis Saha [email protected] 415.783.5374 Microsoft Corporation Mark Wernet [email protected] 503.452.6446 Microsoft Corporation Tom Hoff [email protected] 949.475.3291 3M Manuel A. Moreno [email protected] 520.790.7600

X115 AudaExplore (a Solera Company)

Thomas D. Eggenberger

[email protected] 800.531.9125

AudaExplore (a Solera Company)

John Christenson [email protected] 651.405.4268

EVALUATION COMMITTEE Provide name and title, agency name and mailing address, phone number and email address

Per NAC 333.162 – Each committee to evaluate proposals must contain members that represent at least two (2) using agencies and the chief will not appoint a member to a committee to evaluate proposals

who possesses direct supervisory authority over a majority of the other members of the committee.

Note: Agency must provide a letter from their Administrator or Director approving the evaluation committee

Name and Title Agency Mailing Address (for mailing proposals) Phone Number Email Address

Tonya Laney Sean McDonald Dawn Lietz Amy McKinney Terri Albertson Mark Froese Mani-Karuppuswamy Manivannan

Brian Wilcox Anand Vijayaraghavan Bill Bernard

Page 109: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 109 of 113

EVALUATION COMMITTEE Provide name and title, agency name and mailing address, phone number and email address

Per NAC 333.162 – Each committee to evaluate proposals must contain members that represent at least two (2) using agencies and the chief will not appoint a member to a committee to evaluate proposals

who possesses direct supervisory authority over a majority of the other members of the committee.

Note: Agency must provide a letter from their Administrator or Director approving the evaluation committee Alan Rodgers

Page 110: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 110 of 113

EVALUATION CRITERIA

Per NRS 333.335(3) - Proposals shall be consistently evaluated and scored based upon the following criteria. If you want additional criteria enter it in the “Other” section.

Criteria Weight

1) Demonstrated Competence

a. Did the vendor provide sufficient data to convince you that they will do a good job for the State? b. Was the proof compelling? c. Are you confident that this vendor has the knowledge, skills and abilities to perform all its tasks

well? d. Will the vendor’s resources be adequate to serve the State’s needs? e. Does the vendor suggest new ways to enhance performance? f. Does the vendor have the flexible capacity to handle all the needs of the State as they continue to

change? g. Did the vendor present sufficient performance history to convince you of their ability? h. Has the vendor been in business long enough to provide good stability? i. Has the vendor experienced ownership changes that would impact their services? j. Has there been any censure or litigation history?

2) Experience in performance of comparable engagements

a. Does the vendor have prior experience that will ensure all the skills necessary to perform tasks well? b. Did the vendor have success in other work for a private or governmental entity? c. Does the vendor’s previous work convince you of its successful completion of these duties? d. Has the vendor provided adequate references?

3) Conformance with the terms of this RFP

a. Did the vendor’s proposal provide all the necessary information requested in the RFP in a professional manner?

b. Did the proposal cause doubt regarding the vendor’s ability to complete the necessary tasks? c. Was the proposal easy to understand and did it provide answers to questions, or create more

questions?

4) Expertise and availability of key personnel

a. Is the staff that will be assigned to this project by the vendor the best qualified to manage the process?

b. Will they be available to insure completion of the project? c. Will they be available for follow-up issues? d. Is sufficient staff assigned to handle these duties? e. Is there a Nevada office or contact person? f. Will assigned staff respond to issues within a reasonable amount of time?

5) Cost

a. Has the vendor established a cost that is reasonable for the project? b. Is the State of Nevada receiving good value for its dollars? c. Are the costs reasonable compared to the competition? d. Will there be any additional costs or other ongoing expenses?

Other: DMV may add specific System/Platform evaluation criteria.

Page 111: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 111 of 113

EVALUATION CRITERIA Per NRS 333.335(3) - Proposals shall be consistently evaluated and scored based upon the following criteria.

If you want additional criteria enter it in the “Other” section.

VENDOR PRESENTATIONS Note: Vendor presentations will add additional time to the RFP process.

Do you want vendor presentations? Yes: X No: If so, up to how many vendors? Top 4

System Integration Evaluation Criteria: NOTE: Nevada DMV must qualify the integration vendor at a higher standard than a stand-alone solution vendor as the evaluation of a single system component such as a database purchase from a solution vendor is very different to evaluating an integrator that comes between us and the standards of the products they integrate.

o Security Lens – CC 2.1 o Technical Lens – Functional Requirements + MVIT o Business Lens – TIR Business Needs o Proof of Concept(s) (POC) validation - MVIT

Skill Set Requirements [Minimum]: Min Yrs.

Integration Specialist Foundational Consulting Skill Sets: 1. Independent Verification & Validation Consulting Practices Level IV & V (EPLC) Framework (: CMMI Level 5, Zachman, TOGAF & RUP) 2. Independent Project Oversight Consulting (IPOC) (PMP, MPM)

20 years 20 years

Integration Specialist Foundational Architecture Skill Sets (10-20 years): 1. Chief Architect

2. Enterprise Architect 3. Solution Architect

4. Security Architect 5. Information Architect

6. Business Architect

20 years

20 years 10 years

20 years 10 years

10 years

Integration Specialist Foundational PMO Skill Sets:

1. Senior Project Manager (PMP, MPM, 20 Years) 2. Program Manager (Six Sigma Black Belt 15 Years)

3. Project Manager (PMP 10 Years) 4. Quality Assurance Manager (15 Years)

20 years 15 years

10 years 15 years

Page 112: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 112 of 113

Integration Specialist Foundational IT Skill Sets:

1. Database Design 2. Hybrid Cloud Design

3. Big-Data Design 4. CC 2.1 Security Design

5. IT Acquisition Support 6. IT Process Reengineering

7. IT Project Management 8. IT Project Planning

9. IT Quality Assurance 10. IT Require Analysis

11. IT Strategic Planning 12. IT Systems Analysis

13. Migration Planning

all 10 years

Integration Specialist Foundational Technical Resource Job Category Skill Sets: 1. Application System Analyst I

2. Application System Analyst II 3. Application System Analyst III

4. Data Security Specialist 5. MDM Database Specialist I

6. MDM Database Specialist II 7. EDW Database Specialist III

8. Documentation Specialist (Imaging) 9. Software Engineer I

10. Software Engineer II 11. Hardware Engineer I

12. Hardware Engineer II 13. Network Engineer I 14. Network Engineer II

all 5-8 years

VENDOR PRESENTATIONS EVALUATION CRITERIA

Vendor presentations may be scored based on the original evaluation criteria or new evaluation criteria and weights may be assigned.

Criteria Weight No additional DMV criteria at this time.

Page 113: DMV_SMRFP_IT RFP Development Form_Master_02-06-l5 V 1.0 AD Final

IT RFP Development Form – 02-27-14 Page 113 of 113

VENDOR PRESENTATIONS EVALUATION CRITERIA Vendor presentations may be scored based on the original evaluation criteria

or new evaluation criteria and weights may be assigned.