KNOWINK Oregon Agreement

DocuSign Envelope ID: 01BC0791-8B8F-4414-87D0-37B541571261
TRANSACTION DOCUMENT No. 1
System Implementation Services
As Contemplated Under:
INFORMATION TECHNOLOGY MASTER SERVICES AGREEMENT 16500-00002791
This Transaction Document (consisting of this document and its listed Schedules) is entered pursuant to and is
subject to the Information Technology Master Services Agreement referenced above (the “Agreement”), and is
between the State of Oregon, acting through its Office of the Secretary of State (Agency), and KNOWiNK, LLC
(“Contractor”).
WHEREAS, the Parties entered into the Agreement which contemplates that certain Services to be provided to
Agency by Contractor will be described in Transaction Documents;
WHEREAS, Agency wishes to procure from Contractor the information technology and related services described
in this Transaction Document (the “Services”) to design and implement a voter registration system with the
characteristics described in this Transaction Document (the “System”) from Contractor and Contractor wishes to
provide such Services and System to Agency on the terms and conditions set forth in the Agreement and this
Transaction Document;
NOW, THEREFORE, for valuable consideration, the receipt and sufficiency of which is acknowledged, Agency and
Contractor agree as follows:
1. Definitions and Construction

1.1. Definitions. Unless otherwise defined herein, capitalized terms will have the meaning ascribed to them
in the Agreement. In addition, the terms defined in Schedule 1 to this Transaction Document will have
the meaning set forth therein.
1.2. References to Agreement. The “Agreement” means the Agreement, as it has been or may in the future
be amended, modified, supplemented, revised, or restated by the Parties.
1.3. References to Transaction Document. References to “Transaction Document” in this document and its
Schedules means this individual Transaction Document only and does not mean or refer to any other
Transaction Document that has been or may in the future become part of the Agreement.
2. Term
2.1. Transaction Document Dates. The effective date of this Transaction Document is the date it has been
signed by both Agency and Contractor, and approved as required by applicable law (the “Transaction
Document Effective Date”). Contractor shall provide Services as specified under this Transaction
Document until the earlier of June 30, 2026 (the “Transaction Document Expiration Date”) or the
termination of this Transaction Document in accordance with the terms of the Agreement. The period
from the Transaction Document Effective Date through and including the date of its expiration or
termination is the “Transaction Document Term.”
3. Services
3.1. Services. The Services to be performed and Deliverables to be provided under this Transaction
Document are set forth in Schedule 1, the Statement of Work.
Page 1 of 148
3.2. Service Locations. The Service Locations from which Contractor will provide the Services are set forth
on Schedule 3 to this Transaction Document.
3.3. Requirements. The System Requirements are set forth on Schedule 9, attached hereto and
incorporated herein.
4. Service Levels.
4.1. The Service Levels and the corresponding Fee Reductions applicable to this Transaction Document are
set forth in Schedule 2.
5. Personnel.
5.1. Key Personnel. The Key Personnel for this Transaction Document, including the Contractor’s
Authorized Representative and Project Manager for the Services Described in this Transaction
Document are listed in Schedule 4 to this Transaction Document.
5.2. Agency Personnel. Agency’s Authorized Representative and Project Manager for the Services described
in this Transaction Document are listed on Schedule 5 to this Transaction Document.
5.3. Approved Subcontractors. Subcontractors listed in Schedule 6 are hereby approved to perform under
this Transaction Document.
6. Acceptance Testing; Final Acceptance.
6.1. Acceptance Testing. Contractor and Agency will conduct interim System Acceptance Testing activities
as set forth in Schedule 1, the Statement of Work.
6.2. System Testing. Contractor shall conduct System Testing as set forth in this Section 6.2 and in the
Statement of Work with respect to both the MVP and Phase 2 releases (each as defined in the
Statement of Work). In accordance with Agency’s written notice to proceed with System Testing,
Contractor shall install and test the entire System in the Test Environment in accordance with Schedule
1, in order to determine if the System is in material conformance with Requirements set forth in
Schedule 9 to this Transaction Document, and Agency-accepted Deliverables resulting from the
Requirements Validation Task, and in the Agency-accepted Deliverables resulting from the System
Design Task (the “System Requirements”). If Level 1, Level 2, or Level 3 Defects are discovered in the
System, Contractor shall correct such Defects and retest at no additional charge to Agency prior to
completion of System Testing under this Section. Contractor shall resolve Level 4 Defects at no
additional charge to Agency within Agency-approved timeframes.
6.3. User Acceptance Testing (UAT). Agency will conduct UAT as set forth in this Section 6.3 and in the
Statement of Work with respect to both the MVP and Phase 2 releases (each as defined in the
Statement of Work). After Agency’s acceptance of the System Test Results in the applicable phase (MVP
or Phase 2) and the correction of all known Level 1, Level 2, and Level 3 Defects discovered prior to
UAT, Agency will test the entire System by using it in off-line processing using both test data and the
Agency’s converted operational data in order to determine if the System is in material conformance
with the System Requirements. Contractor shall deliver UAT Services in accordance with the UAT Task
in Schedule 1. Agency will notify Contractor in writing of each Defect discovered during UAT in
accordance with the Accepted Test Plan and specify its level. Contractor shall correct all Level 1, Level 2,
and Level 3 Defects identified during UAT at no additional charge to Agency and resubmit the corrected
System to Agency for retesting within ten (10) Business Days of a written notice of Defect. All such
retesting will be done on an iterative basis and be completed by Agency no later than ten (10) Business
Days after Contractor submission of the corrected System. Contractor shall correct all Level 1 Defects,
Page 2 of 148
Level 2 Defects, and Level 3 Defects prior to completion of UAT activities under this section. Contractor
shall resolve Level 4 Defects discovered during UAT at no additional charge to Agency within Agency-
approved timeframes.
6.4. Implementation and Mock Elections. After Agency’s Acceptance of the UAT Report in a phase, and
upon Agency’s notice to proceed with the System Implementation Task for the phase, Contractor shall
install the System in the Agency-approved Environment. If the Statement of Work calls for the conduct
of a Mock Election, Contractor shall prepare the Mock Election for Agency in accordance with the
Statement of Work. In addition to conducting any Mock Election, Agency and Counties will test the
entire System implemented in that phase in order to validate that the System is functioning in the
Agency-approved Environment, validate the Implementation methodology, validate the user and site
preparedness activities, and determine if the System is in material conformance with the Agreement
Requirements.
6.5. System Stabilization Period.

Upon completion of the Implementation as set forth in Section 6.4, including the conduct of any Mock
Election required by the Statement of Work, and Contractor’s correction of identified Level 1, Level 2,
and Level 3 Defects, and upon Agency’s notice to proceed, Contractor shall fully implement the System
implemented in that phase in the Production Environment in accordance with Schedule 1. After
Implementation, Agency will use the System for processing of System data in Production for a period of
90 Calendar Days (a “System Stabilization Period”) to determine if the System is stable, complete, and
operating correctly.
6.5.1. If Defect(s) are discovered during a System Stabilization Period, Agency will notify Contractor of
the Defect in writing as soon as practical, describing the Defect and specifying its level. Upon
receipt of such written notice, Contractor shall correct any Level 1 Defect within four (4)
consecutive hours, any Level 2 Defect within twenty four (24) consecutive hours, and any Level 3
Defect within three (3) Business Days from the time of the written notice, and submit the
corrected System to Agency for validation in accordance with this Section, at no additional
charge to Agency. All such validation will be completed by the Agency no later than three (3)
Business Days after Contractor submission of the corrected System.
6.5.2. At the end of each System Stabilization Period, if any Level 1, Level 2, or Level 3 Defects
discovered during the System Stabilization Period remain uncorrected, Agency will grant
Contractor one additional five (5) Business Day period from the end of the System Stabilization
Period to correct such Defects. If the Defects are not corrected during that period, unless
Agency in its discretion allows additional time for correction, Agency may declare a material
breach of this Transaction Document by Contractor.
6.5.3. The parties will set priorities for Level 4 Defects remaining at the end of a System Stabilization
Period, and Contractor shall correct such Defects during one or more a maintenance release(s)
to be delivered on an agreed upon schedule.
6.5.4. Completion of the System Stabilization Period following Phase 2 will mark the end of the
Implementation Task.
Page 3 of 148
6.6. Resolution of Defects During System Stabilization Period. If Defect(s) are discovered during a System
Stabilization Period, Agency will notify Contractor of the Defect in writing as soon as practical and
Contractor shall correct the Defect as set forth in the Statement of Work. Contractor shall resolve any
Level 1 or 2 Defect(s) as set forth in the Statement of Work, and the System Stabilization Period will be
restarted at day 1 upon Agency’s Acceptance of the corrections of the Defect, including any required
Acceptance Tests. When a Level 3 Defect is identified, the System Stabilization Period will pause, will
recommence upon Agency’s Acceptance of the correction of the Defect, including any required
Acceptance Tests, and will end, absent the discovery of any additional Defects, on the date that is the
later of (i) fourteen Calendar Days following Agency’s Acceptance of the correction of the Level 3
Defect, or (ii) the expiration of the System Stabilization Period.
6.7. Final Acceptance. “Final Acceptance” of the Services described in this Transaction Document and the
System will occur when the following events have occurred, or conditions exist:
6.7.1. Agency has notified Contractor that the System meets all Acceptance Criteria and that all
Acceptance Tests required pursuant to the SOW have been successfully completed for the
System;
6.7.2. The System is stable, complete, and operating correctly as specified in the SOW, without Level 1
Defects, Level 2 Defects, or Level 3 Defects;
6.7.3. Agency has received any Governmental Approvals required by Law to use the System and the
Application Services for their intended purpose;
6.7.4. All Documentation is complete, inventoried, and Accepted by the Agency. Contractor shall
provide all text Documentation both in hard copy and in an electronic format as specified in the
Statement of Work; and
6.7.5. Contractor has completed and Agency has Accepted Deliverables for User Training, Technical
Training, and other knowledge transfer as specified in SOW.
7. Warranties and Warranty Period.
7.1. Additional Warranties. In addition to the representations and Warranties set forth in the Agreement,
Contractor hereby makes the following representations and warranties with respect to the Deliverables
and Services that are the subject of this Transaction Document:
[NONE]
7.2. Post-Implementation Warranty Period. Contractor shall warrant the System During the Post-
Implementation Warranty Period. During the Post-Implementation Warranty Period, Contractor shall,
at no additional charge to Agency, furnish such materials and Services necessary to correct any Defects
in the System that prevent the System from meeting the Acceptance Criteria and Agreement
warranties. Contractor shall cure Defects discovered during the Post-Implementation Warranty Period
that prevent the System from meeting the Acceptance Criteria and Agreement warranties. For
purposes of this Section, “Post-Implementation Warranty Period” means the period that begins on the
date of the completion of the Phase 2 System Stabilization Period and ends on the date that is the
earliest of (i) 12 months from that date, or (ii) 6 months from that date if the System has experienced
no errors that are Criticality 1 or Criticality 2 (as defined in Schedule 2 to this Transaction Document)
during that 6 month period.
7.3. System Change Warranty Period. Contractor shall warrant System changes that modify or enhance the
System Accepted at Final Acceptance, and that are not Defect corrections, for a period of ninety (90)
Calendar Days following Acceptance of the implemented System change. Contractor shall, at no
Page 4 of 148
additional charge to Agency, furnish such materials and Services necessary to correct any Defects
relating to the System change that prevent the System from meeting the Acceptance Criteria and
Agreement warranties. Contractor shall cure Defects discovered during the System Change Warranty
Period that prevent the System from meeting the Acceptance Criteria and Agreement warranties.
8. Licenses
8.1. Contractor Intellectual Property. The licenses for Contractor Intellectual Property that Contractor is
required to deliver under this Transaction Document are set forth in Schedule 7 to this Transaction
Document.
8.2. Third Party Intellectual Property. The licenses for Third Party Intellectual Property that Contractor is
required to deliver under this Transaction Document are set forth in Schedule 8 to this Transaction
Document.
9. Charges.
9.1. Payments. Agency shall pay Contractor the fixed prices set forth in the Payment Schedule of the
Statement of Work for Contractor’s completion and Agency’s Acceptance of the Services and
Deliverables Contractor will deliver under this Transaction Document. All invoices and payments will
comply with the terms of the Agreement.
9.2. Transaction Document Maximum-not-to-exceed Compensation. Notwithstanding any other provision
of this Transaction Document to the contrary, the maximum, not-to-exceed compensation that Agency
will pay to Contractor under this Transaction Document is $9,845,000.00 (the “Transaction Document
Maximum Not-To-Exceed Compensation”), which includes payment for any allowable expenses for
which Contractor may request reimbursement under this Agreement.
9.3. Expenses. Agency will not reimburse Contractor for expenses incurred by Contractor in the
performance of Services under this Transaction Document.
10. Severability. The parties agree that if any term or provision of this Transaction Document is declared by a
court of competent jurisdiction to be illegal or in conflict with any law, the validity of the remaining terms
and provisions will not be affected, and the rights and obligations of the parties will be construed and
enforced as if this Transaction Document did not contain the particular term or provision held to be invalid.
11. Counterparts. This Transaction Document may be executed in several counterparts, all of which when taken
together constitute one contract binding on all parties, notwithstanding that all parties are not signatories to
the same counterpart. Each copy of this Transaction Document so executed constitutes an original.
12. Headings. The headings in this Transaction Document are included only for convenience and do not control
or affect the meaning or construction of this Agreement.
13. Integration. This Transaction Document and attached Schedules constitute the entire agreement between
the parties on the subject matter hereof. There are no understandings, agreements, or representations, oral
or written, not specified herein regarding this Transaction Document.
14. Certification. By signature on this Transaction Document, the individual signing below on behalf of
Contractor certifies under penalty of perjury that: a) the undersigned is authorized to act on behalf of
Contractor; and b) the representations, warranties and certifications contained in the original Agreement
are true and correct as of the effective date of this Transaction Document and with the same effect as
though made at the time of this Transaction Document.; and b) the undersigned is authorized to act on
behalf of Contractor and that Contractor is, to the best of the undersigned’s knowledge, not in violation of
Page 5 of 148
any Oregon Tax Laws. For purposes of this certification, “Oregon Tax Laws” means a state tax imposed by
ORS 320.005 to 320.150 (Amusement Device Taxes), 403.200 to 403.250 (Tax For Emergency
Communications), 118 (Inheritance Tax), 314 (Income Tax), 316 (Personal Income Tax), 317 (Corporation
Excise Tax), 318 (Corporation Income Tax), 321 (Timber and Forest Land Taxation) and 323 (Cigarettes And
Tobacco Products) and the elderly rental assistance program under ORS 310.630 to 310.706 and any local
taxes administered by the Department of Revenue under ORS 305.620.
CONTRACTOR, BY EXECUTION OF THIS TRANSACTION DOCUMENT, HEREBY ACKNOWLEDGES THAT

CONTRACTOR HAS READ THIS TRANSACTION DOCUMENT, UNDERSTANDS IT, AND AGREES TO BE BOUND BY ITS
TERMS AND CONDITIONS.
CONTRACTOR: YOU WILL NOT BE PAID FOR SERVICES RENDERED PRIOR TO AGENCY OBTAINING ALL NECESSARY
STATE APPROVALS.
THE STATE OF OREGON, ACTING THROUGH ITS OFFICE OF SECRETARY OF STATE
By: ________________________________________________________________________________
Deborah Scroggin
Name: ______________________________________________________________________________
Elections Director
Title: ________________________________________________________________________________
7/1/2021
Date: _______________________________________________________________________________
[CONTRACTOR]
By: ________________________________________________________________________________
Scott Leiendecker
Name: ______________________________________________________________________________
Scott Leiendecker
Title: ________________________________________________________________________________
6/29/2021
Date: _______________________________________________________________________________
Page 6 of 148
SCHEDULE 1 – STATEMENT OF WORK
A. Project Overview
The Oregon Centralized Voter Registration System (OCVR) is a critical application used by County and state
elections employees to manage election and voter records. OCVR is now over 15 years old and needs significant
enhancements or replacement. The Agency currently has Help America Vote Act (HAVA) funding and intends to
use that funding to modernize the current OCVR. During the year 2020, the Agency identified this project and
began project initiation activities. The Agency outsourced the major requirements-gathering effort for the RFP
to a consultant, and conducted various workshops and interviews with the Agency, Counties, and other
stakeholders (e.g. owners of interfacing systems), to develop the requirements.
In the current ecosystem, OCVR, the Oregon Election System for Tracking and Reporting (ORESTAR), and Election
Business Systems (EBS) contain duplicate data, and the scheduler does not allow information to flow between
systems in real-time. The Agency is managing and maintaining multiple databases and the current platform lacks
the ability to easily implement modern security best practices (like multi-factor authentication). County Elections
offices have minimal tools to improve the voter experience and have difficulty keeping voters updated on the
status of their voter registration and completed ballots. OCVR has significant challenges in communicating with
third-party systems that are critical to the election process, such as tabulators and scanners.
After reviewing RFP proposals, Agency selected Contractor to provide the System to:
1. Improve the pain points discussed above.

2. Achieve additional desired functionality to improve the efficiency of administering elections.
3. Enhance voter communications and transparency.
4. Optimize business processes within the State and Counties in using and supporting the System.
B. Project Standards
This Part B of the Statement of Work details the standards, limitations, and constraints of the Project.
Definitions
Acronyms and Project-specific terms are defined in Part E of this Statement of Work.
Guiding Principles – Future State Vision

The following represents the guidance principles for configuration and customization developments, and to
illustrate a framework for OCM activities. Deviations from these guiding principles during Project work must be
documented with an explanation for the deviation, and written approval from the Agency PM.
Page 7 of 148
Guiding Principle Description

Standard, out-of-box processes aligned to industry best practices will be
the default approach over customization, unless required to support a
Align to Best Practices valuable differentiating Agency or County need. Exceptions will be
considered to accommodate unique legislative, fiscal, regulatory or security
requirements.
Operational improvements that benefit the Agency and County Elections
Prioritize Requirements Offices will be prioritized over improvements that benefit only a small
subset of stakeholders.
Elections are critical to our community, but also a non-revenue producing
activity. As a result, the System will look for opportunities to improve
Increase Internal
efficiency through use of automation, real-time data sharing, advances in
Efficiencies
new technology, the reduction of technical debt, and is user friendly so as
to reduce training needs.
To improve the voters and the Counties ability to communicate,
Enhance Voter incorporate portals, integrated calendars, and communications features to
Communication effectively manage voter history and improve communications using tools
such as SMS text and email in addition to “snail mail” notifications.
To improve reporting, overall data quality, and security, Agency and the
Improve Data Integrity,
Counties will standardize data as much as possible, incorporate data
Sharing, and Security
validation and privacy/security best practices within the System.
Deliverable Expectation Documents

When a Deliverable’s Acceptance Criteria includes an Agency-accepted DED (Deliverable Expectation
Document), Contractor shall prepare a DED for Agency’s review and feedback. The DED template and the
deliverable review and approval processes will be provided as part of the Project Management Plan. The
Deliverable Acceptance Request (DAR) template will also be provided as part of the deliverable review and
process methodology in the PMP. Each DED must document, at a minimum, the following:
 Project Name
 Deliverable Name
 applicable SOW references (Task and Deliverable #)
 Deliverable outline/brief description;
 Additional Deliverable requirements, as mutually agreed during Requirements Validation;
 Acceptance Criteria for the Deliverable;
 Agency and Contractor’s review and approval timeline, if different than the periods set forth in Section
4.6 of the Agreement; and
 Signature line for Agency approval.
Page 8 of 148
Documentation Formatting
Unless otherwise noted for a given Deliverable, all Deliverables should be provided in one of the following file
formats:
File Format Description
.pdf Portable Document Format
.docx Microsoft Word
.xlsx Microsoft Excel

.csv Comma Separated Value
.vsdx Microsoft Visio
All other file formats must be approved by the Agency Project Manager prior to Deliverable submittal.
State of Oregon Holidays

The following are the State of Oregon Holidays that are observed by the Agency:
1. New Year’s Day;

2. Martin Luther King Jr. Birthday;
3. Presidents Day;
4. Memorial Day;
5. Juneteenth;
6. Independence Day;
7. Labor Day;
8. Veterans Day;
9. Thanksgiving Day;
10. Day After Thanksgiving;
11. Christmas Day; and
12. Any day appointed by the Governor or Secretary of State as a holiday.
C. Tasks, Deliverables, Periods of Performance, and Acceptance Criteria

This Part C of the SOW details the following:
 Tasks and Services to be performed;

 Period of Performance for each Task;
 The Deliverables required of the Contractor; and
 The Acceptance Criteria for the Deliverables.
Deliverable deadlines are specified in Part D of this SOW. The Project Schedule that Contractor completes
pursuant to Task 1.1 will include a Delivery Schedule for the Services described in this SOW. Upon Agency’s
Page 9 of 148
Acceptance of Deliverable 1.0, the Project Management Plan, the Delivery Schedule set forth in the Project Plan
will become binding on the Parties. The Parties may amend the Delivery Schedule by agreeing in writing to a
revised Delivery Schedule, which will replace the then-current Delivery Schedule. The Delivery Schedule most
recently signed by both Parties shall be the Delivery Schedule for the Services set forth in this Transaction
Document.
Task 1.0 – Project Management

Period of Performance: Transaction Document Effective Date thru Project Closeout.
Purpose and Objective: Ensure ongoing coordination between Agency and Contractor during the Project’s
period of performance up until Project Closeout. The objective is for Contractor to work with Agency’s Project
Manager to set up roles, responsibilities, record-keeping systems, lines of communication, and procedures for
managing the Project, assuring quality, managing technical configuration, and controlling Project changes.
The Contractor shall follow project management best practices, and both Contractor’s activities and Deliverables
shall be consistent with the Project Management Institute (PMI) and Project Management Body of Knowledge
(PMBOK).
Agency Responsibilities: Contractor shall perform all Services and provide all Deliverables required of this Task.
To that end, Agency will:
 Prepare and maintain the Agency’s Project Management Plan.

 Provide access to Agency’s communication system and document collaboration library (currently MS
Teams).
 Review and provide feedback on Contractor’s Project Management Deliverables.
 Schedule meeting dates/times for meetings that include State and County official participation,
including the Oregon Votes Steering Committee.
 Manage Agency’s resources, including its authorized agents under contract with Agency (except for
Contractor).
 Provide contact information and facilitate additional State resources as and when requested by
Contractor (e.g., Oregon DMV, DAS P&D, ERIC).
 Submit Project Change Requests to Contractor, when needed.
 Review and approve or deny Contractor Project Change Requests. If denied, an explanation will be
provided to Contractor.
Deliverable(s) and Acceptance Criteria
All Deliverables and Acceptance Criteria are specified in the subtasks below.
Task 1.1 – Project Planning

Contractor shall develop and provide a Project Management Plan, initial training plans, and additional
Deliverables related to the software development lifecycle for this Project.
Page 10 of 148
Contractor shall provide the following:
No. Deliverable Description Acceptance Criteria

1.0 Project Management The Project Management Plan must outline how the  Agency-
Plan Contractor will manage the Project throughout the accepted DED.
Project lifecycle. The Project Management Plan must  Deliverable
include, at a minimum, the following components, and contains all
subsidiary plans: criteria agreed-
 Scope Management Plan (Deliverables & upon in the
Acceptance Criteria, Project Approach, Exclusions, DED.
Constraints and Assumptions, Goals).  Agency PM
 Requirements Management Plan. approves the
PM Plan.
 Change Management Plan – The Change
Management Plan should define that Change
Requests are:
o Created by the Oregon Votes Project Team;
o Reviewed and edited by the Agency Project
Manager;
o Approved or Rejected by the Oregon Votes
Steering Committee;
o Implemented by the Oregon Votes Project
Team; and
o Updated by the Contractor to reflect the
project schedule and cost estimates when
change requests are approved.
 Work Breakdown Structure (WBS) and Schedule
Management Plan – The WBS must include:
o A consolidated view of the activities, activity
descriptions, and activity durations assigned
to the Oregon Votes Project Team, the
Contractor, and the External QA Consultant;
o Resources assigned to each activity;
o A list of Deliverables tied to project
milestones;
o A method to track the project schedule
against the planned schedule; and
o DED and Deliverable submission and approval
periods.
 Testing and Quality Management Plan
 Resource Management Plan
 Communication Management Plan
 Risk Management Plan
 Stakeholder Engagement Plan
 Release Management Plan
Page 11 of 148
Task 1.2 – Project Kickoff Meeting

Contractor shall schedule, lead, and participate in a Project Kickoff Meeting with the Oregon Votes Project
Team. Contractor shall start the meeting in a presentation format. The purpose of the Project Kickoff Meeting is
to review all the components described above in the Project Management Plan and the various Deliverables
associated with the Project. The Contractor shall lead the discussion of the following Project activities for all the
stakeholders to gain an understanding of the process, roles, and responsibilities:
 Roles - Understanding of the roles of various project stakeholders including the Oregon Votes Steering
Committee, Project Sponsor, Agency’s Project Manager, Oregon Votes Project Team, and Contractor’s
Project team.
 Stakeholders - Identification of key stakeholders to be contacted to review and validate information
relative to all steps throughout the Project.
 Work Plan - Review of the Project work plan.
 Deliverables - Review of the Deliverables of the Project work plan.
 Project Schedule - Review of the Project schedule.
 Mock Project Risk Discovery – Review of Project risks and shared lessons-learned.

The Project Kickoff Meeting  Copy of presentation provided to OR
Presentation must include the Votes PM prior to meeting.
following topics:  Presentation accurately addresses at
 Project Overview least all topics identified in the SOW.
 Objectives and Definitions  Attendees are able to indicate that
Project Kickoff  Roles and Responsibilities they understand the topics
1.1.1 Meeting presented.
 Project WBS
Presentation  Contractor attends the meeting and
 Project Deliverables
performs the presentation.
 Project Schedule (high-level)  Contractor takes notes and performs
 Keys to Success follow-up after the meeting, if
 Next Steps necessary, to ensure all questions are
 Questions and Answers (Q&A) answered.
Documentation of all substantial
 All questions asked during the Project
Project Kickoff decisions, agreements, and follow-up
1.1.2 Kickoff Meeting are documented
Meeting Notes questions asked and their respective
with corresponding answers.
answers.
Task 1.3 – Status Reports

Contractor shall schedule, attend, and participate in regular Project status meetings to discuss progress, issues,
resolutions, and next steps.
Page 12 of 148
In preparation for these meetings, Contractor shall develop and deliver Bi-weekly Project Status Reports during
the implementation phases of the Project. Contractor shall provide these status reports on a regularly scheduled
basis, delivered once every other week to the Agency’s PM.
Contractor shall also attend and participate in monthly Oregon Votes Steering Committee Meetings with the
Oregon Votes Project Team. Contractor shall provide updates to the Committees using the Monthly Steering
Committee Meeting Reports.

 Includes enough detail to drive
Contractor shall follow the reporting
Project status meetings.
format provided by Agency. Each
 Status documents verifiable
report must, at a minimum, address
Bi-Weekly Project progress being made on the
1.2.1 the following:
Status Reports Project.
 Status reports
 Reports provided up until Agency
 Issues list
acceptance of Project Closeout
 Risk management updates
activities and Deliverables.
 Includes enough detail to drive
Contractor shall follow the reporting
Project status meetings.
format provided by Agency. Each
 Status documents verifiable
Monthly Steering report must, at a minimum, address
progress being made on the
1.2.2 Committee the following:
Project.
Meeting Reports  Status reports
 Reports provided up until Agency
 Issues list
acceptance of Project Closeout
 Risk management updates
activities and Deliverables.
Task 1.4 – Quarterly Project Scope Reviews

Contractor shall schedule and participate in quarterly Project Scope Review Meetings with Agency to:
 Review Project progress and validate the scope and requirements; and
 ensure that all scoping elements are being addressed and that nothing is missed during Project
performance.
Contractor shall document the outcomes of the Project Scope Review Meetings, and deliver it to the Agency’s
PM.
Page 13 of 148
 Contractor attends
and participates in
Quarterly Project These notes must document the scope and Quarterly Project
1.3 Scope Review requirement elements reviewed, and the Scope Review
Meeting Notes disposition for each. Meetings.
 Agency PM approves
Contractor’s notes.
Task 2.0 – Organizational Change Management
Period of Performance: June 2021 thru February 2023.
Purpose and Objective: Manage and facilitate business process changes to optimize the value gained from the
System and ensure County satisfaction. The primary goal of this Task is to smooth out the friction Users will
experience in adapting to a new system. As part of this work, the Contractor shall facilitate business process
mapping (as-is and to-be) and document the to-be business process decisions so as to inform the
implementation and training plans.
 Identify the OCM audience, including:

o Communication to the Oregon Votes Subcommittee
o Communication to stakeholders (Counties, State personnel, vendors, third parties, and so on)
o Communications to the public
 Distribute OCM communications.
 Create a notice of, and contact list for, communicating changes resulting from the OCM Gap Analysis.
 Develop initial list of processes pulling from previous research and internal knowledge.
 Setup a meeting with the Sub-committee to provide background and additional context of this Task and
its subtasks and ask the Sub-committee to complete a list in advance of the OCM phase.
Task 2.1 – Gap Analysis

Contractor shall:
 Perform a gap analysis to document current process and map those processes to the functionality of the
System.
 Document how the existing processes will change with the System.
 Capture the current process narrative, the new process narrative, and the summary of the change
between the two.
 Develop and review as-is processes with the Oregon Votes County Subcommittee.
Page 14 of 148
 Develop and deliver job and process maps that identifies needed organizational changes in order to
optimize the value realized by the System.

 Agency-accepted DED.
 Deliverable contains all criteria
agreed-upon in the DED.
 Documents a process taxonomy
 Review existing process and gather that identifies the most critical
domain knowledge to create as-is processes supporting successful
process documentation that is election management and voter
transparent, easy to follow, and uses registration.
standard notation to clearly  The taxonomy allows the team
document relevant roles within the to prioritize which to-be process
As-is Job and process. documents to create.
2.1.1
Process Mapping  Document current voter registration  Approval from the Oregon Votes
and election management Project Team that as-is
processes. processes are accurately
 Define User processes within OCVR. captured from the State
 Identify the roles and perspective.
responsibilities at the County and  Approval from Oregon Votes
State to manage the as-is processes. County Subcommittee that as-is
processes are accurately
captured from the Oregon
County perspective.
 Document the gap between the old
and new processes.
 Define the delta in the process from
 As-is and to-be gaps
OCVR to the System.
documented for both State and
 Identify personnel needs to facilitate
County personnel.
ongoing management of the System
 To-be job role maps identify
to support the Counties.
levels of effort and expertise
 Document future state processes
To-be Job and needed for State personnel to
2.1.2 that reflect the System and related
Process Mapping support the Counties in the
job roles including improvement
System.
opportunities and new methods to
 Oregon Votes County
improve accuracy, efficiency, and
Subcommittee approves To-be
transparency.
process methods.
 Identify the roles and  Achieves leadership alignment
responsibilities at the County and and County buy-in by receiving
State to manage the to-be approval from the Oregon Votes
processes. County Subcommittee.
Page 15 of 148
 Identify standardized to-be

workflows and common
methodologies for Counties.
Task 2.2 – Communication Plan

Contractor shall develop and deliver a plan to:
 notify Counties of the changed business and operational processes resulting from the gap analysis; and
 notify existing employees (that will be impacted by the “To-Be” state) of the changes resulting from the
gap analysis.
Contractor shall facilitate discussions and support a feedback mechanism for impacted County and Agency
employees.

 Documents the communication  Agency-accepted DED.
strategies and approach, including for  Deliverable contains all
reinforcement activities. criteria agreed-upon in the
 Defines the OCM goals and objectives. DED.
 Leadership alignment strategy.  Communication strategies
 Defines future communication identifies target audiences,
protocols. and approaches are tailored
 Methodology to build awareness and to the different audiences.
execute changes in the following  OCM goals and objectives
areas: align with the Future State
o System features Vision Guiding Principles.
Organizational o Security architecture  Describes and provides
Change o Technology components templated design and
2.2.1 Management o Workflow and configuration formatting standards for
Communication specifications future OCM Communication
Plan o Screens and views Materials.
o Forms and report parameters  Demonstrates an ongoing
o Data migration and data two-way communication
transformation tasks feedback mechanism with the
 Be designed and formatted in a different target audiences.
manner to engage State and County  Achieves leadership alignment
employees. and County buy-in by
 Provides all associated communication receiving approval from the
resources to execute the strategy and Oregon Votes Steering
approaches defined in this plan. Committee.
 Identifies the communication
feedback mechanism(s).
Page 16 of 148
 Agency PM provides written

Development of communication materials
OCM confirmation that this
that are aligned with the OCM
2.2.2 Communication Deliverable aligns with the
Communication Plan, which Agency can
Materials OCM Communication Plan’s
distribute timely throughout the Project.
goals and objectives.
Task 2.3 – Training Strategy

Contractor shall ensure training plans and materials incorporate the considerations of the gap analysis (i.e., as-is
and to-be mapping) delivered and Accepted in Task 2.1.

Identification of the  Deliverable contains all criteria agreed-upon in
pertinent elements of the the DED.
Training
gap analyses that are to be  Identifies how the training approach will address
2.3 Strategy
incorporated into the the gaps between Deliverables 2.1.1 and 2.1.2.
Document
training documentation and  The Oregon Votes Project Team confirms and
Deliverables. approves that pertinent elements of the gap
analysis have been incorporated.
Task 2.4 – Change Reinforcement Plan

Contractor shall be responsible for ensuring agreed-upon and accepted business process changes are reinforced
with Agency and the Counties. Contractor shall develop and deliver a Change Reinforcement Plan to accomplish
the objective of this Task for ensuring the realization of optimal value gained from the System in the long term.
Contractor shall provide status updates to the Agency’s PM, reporting on the progress of change acceptance and
identifying any issues and recommended remediation efforts.
Page 17 of 148

This Deliverable must address the  Addresses risks and mitigation
following: strategies in the areas of
 Purpose. change resistance, Agency and
 Risks are identified, and mitigation County leadership, operational
strategies defined for each risk. disruptions, and avoidance of
 The process for identification and forcing change.
Change documentation of monthly lessons  Monthly lessons learned
2.4.1 Reinforcement learned. section identifies how to
Plan  Assessment intervals and promote successful behaviors
adoption/performance metric in an ongoing manner during
definition. change reinforcement
 Clear roles, responsibilities, and reporting.
governance.  Oregon Votes Project Team
 Plan to promote new successful approves the cadence of the
behaviors. assessment intervals.

 Approved by the Oregon Votes
Steering Committee.
Assessing and analyzing performance – At  Agency-accepted DED.
regular intervals, assessments are  Deliverable contains all criteria
performed to measure Project metrics for agreed-upon in the DED.
tracking adoption and performance.  Agency continues to receive
this Deliverable on a regular
Diagnosing gaps & issues during and post monthly basis until Agency’s
implementation – Ongoing analysis will be Acceptance of the Phase 2
performed to identify areas of resistance System Deployment.
Monthly Change and issues to uncover the causes of any
2.4.2 Reinforcement gap between current performance and
Progress Reports desired performance.
Taking necessary corrective action –

Remediation efforts will include such steps
as identifying any new training needs,
updating training content, working with
managers and leaders to communicate
relevant changes and reinforce
expectations.
Task 3.0 – Requirements Validation

Period of Performance:
Phase Target Start Target End
Page 18 of 148
MVP June 2021 October 2021

Phase 2 October 2022 December 2022
Purpose and Objective: In this Task, the Contractor shall lead and facilitate the process for developing the
detailed System functional and non-functional requirements documentation based on Schedule 9 in this
Transaction Document.
Contractor shall complete the following activities in the development of detailed requirements:
 Review in detail all existing use case documentation and requirements developed by the Agency.
 Perform interviews with Agency Subject Matter Experts, defined by the Agency PM, to understand how
the baseline requirements shall be translated into the technical details required for System
requirements.
 Develop a draft System requirements methodology that addresses the approach and tools to ensure
alignment with the Requirements and capture the level of detail necessary.
 Review draft System requirements methodology with the stakeholders designated by Agency, allowing
time for those stakeholders to return comments or clarifications.
 Prepare final System requirements methodology based on updates from stakeholders designated by
Agency.
 Prepare and deliver the detailed functional and non-functional requirements traceability matrices.
 Provide clarification on the Requirements listed in Schedule 9 of this Transaction Document.

 Solicit feedback and request confirmations from Counties.
 Identify the appropriate Subject Matter Experts for Contractor’s interviews.
 Provide interpretation and make decisions related to applicable Election Laws, including any subsequent
legislation passed by the Oregon Legislature during the Period of Performance.

 Elaborated Non-Functional  Agency-accepted DED.
Requirements, based on the analysis  Deliverable contains all
completed in Task 3.1. criteria agreed-upon in
 Elaborated Functional Requirements the DED.
Detailed Requirements
3.1 based on the analysis completed in  Requirements are
Traceability Matrix
Task 3.2. elaborated in greater
 Elaborated Interface Requirements detail using the baseline
based on the analysis completed in Requirements in
Tasks 3.3 & 3.4. Schedule 9.
Page 19 of 148
 Requirements are
categorized as MVP or
Phase 2.
 Agency PM approval.
Based on the analysis completed in Task

3.5, either: (a) Revisions to the Detailed
Phase 2 Requirements Requirements Traceability Matrix after
3.2  Agency PM approval.
Traceability Matrix MVP Deployment, or (b) written
confirmation from Contractor and Agency
that no revisions are necessary or required.
Task 3.1 – Non-Functional/Technical Requirements Validation

Contractor shall elaborate on the Non-Functional Requirements of the System in Schedule 9 to include, at a
minimum:
 Confirming System components from OCVR and related legacy systems;

 Hosting, architecture, and platform Requirements;
 Validate or expand on the baseline Non-Functional Requirements provided in Schedule 9 of this
Transaction Document; and
 Incorporate Agency feedback on the elaborated Non-Functional Requirements.
Task 3.2 – Functional and Reporting Requirements Validation

Contractor shall elaborate on the Functional and reporting Requirements of the System provided in Schedule 9
to include, at a minimum:
 Voter registration;
 Managing addresses and jurisdictions, including considerations for TotalAddress;
 Petitions;
 Election Management and Processing (including tabulation, ENR, Ballot receipt, and Signature
Verification);
 Notices;
 Reports;
 Election Worker;
 System Administration; and
 Public (Online) Portal.
Contractor shall Incorporate Agency feedback on the elaborated Functional and reporting Requirements.
Page 20 of 148
Task 3.3 – HAVA Interface Requirements Validation

Contractor shall complete an analysis for HAVA interface requirements and incorporate those findings into the
elaborated Interface Requirements in Schedule 9.
Task 3.4 – Confirm and Validate Other System Interfaces

Contractor shall elaborate on the Interface Requirements of the System provided in Schedule 9. In addition to
this elaboration, Contractor shall coordinate with Agency to note any additional system interfaces that are
required to satisfy the Requirements.
Task 3.5 – Phase 2 Requirements Review and Validation

After implementation of the MVP, Contractor shall review and confirm the Phase 2 System Requirements. If
additional Requirements are necessary, per Contractor or Agency, Contractor shall document revisions to the
Requirements in the Requirements Traceability Matrix.
Task 4.0 ─ System Design


MVP June 2021 March 2022
Phase 2 November 2022 April 2023
Purpose and Objective: System design includes application design, interface design, and conversion design.
Detailed and logical application design documents produced by the Contractor shall direct the System
development efforts. The design function is driven by the outputs of the requirements validation. These
documents provide the framework essential to ensure that the System is constructed consistently with
appropriate software development methodologies and the functionality defined through the Requirements.
The Contractor shall conduct a review of the System functional and non-functional Requirements to identify
required modifications and Enhancements to any pre-existing component or functionality that the Contractor
plans to leverage for the System. Contractor shall hold design sessions along with appropriate staff from the
Oregon Votes Steering Committee and the External QA Consultant. The Contractor shall conduct Joint
Application Development (JAD) sessions to fully explore and understand existing voter registration functionality
that the Contractor shall leverage for the System, and to understand the gaps to be addressed to fulfill the
remaining required functionality for the System. Based upon these gap analysis JADs, the Contractor shall
document in detail the design and development actions necessary to fully meet Requirements for both the MVP
and Phase 2 implementations of the System. Based on the JAD sessions Contractor shall prepare and deliver the
design documents describing both MVP Requirements and Phase 2 Requirements.
The development of the System must include the following:
 Define a conceptual architecture that shall produce a design to fulfill the functional Requirements, and
that can be realized at a technical level.
Page 21 of 148
 Define the interfaces for each third-party entity and include data field definitions and their validation
rules. The logical architecture must produce a design to fulfill the functional Requirements.
 Define the details around the integration layers, potentially using Web Services and various other
integration technologies. The physical architecture shall produce a design to fulfill the stakeholders’
functional Requirements and that can be technically achieved by the Contractor.
 Identify all appropriate Project stakeholders for design sessions.

 Provide Contractor with Project stakeholder schedule availability.
 Review and provide feedback on draft design documents.
 Clarify design requirements for Contractor.
Task 4.0 Deliverable(s) and Acceptance Criteria
Task 4.1 – Functional Design

Contractor shall develop and provide a comprehensive Functional Design Document (FDD) to Agency.
Contractor shall maintain components of the design throughout the course of the Project and updated when
any System design changes occur.
The Contractor shall conduct a walkthrough of the FDD with the Oregon Votes Steering Committee and the
External QA Consultant to validate the contents of the FDD. The FDD must incorporate all information from the
design sessions and all Functional Requirements.

Describe how the System enables the Functional  Agency-accepted
and Non-Functional Requirements of the Agency. DED.
Contractor shall work with the Oregon Votes  Deliverable contains
Steering Committee to identify functional design all criteria agreed-
requirements. The FDD artifact must include the upon in the DED.
Functional Design following components:  Agency PM approval.
4.1  Details on which components will be
Document (FDD)
leveraged from existing systems and which
components must be newly developed.
 Business rules.
 Reporting capabilities and prebuilt reports.
 User profiles and security role permissions.
Page 22 of 148
 System functionality traceable back to the

functional requirements traceability matrix.
 System overview diagrams.
 Domain model.
 Process flows.
Task 4.2 – Technical Design

Contractor shall schedule, attend, and participate in technical design sessions with Agency in order to develop
and deliver a technical design to the Agency.
The Technical Design Document (TDD) must include, at a minimum, the interface definitions and design. The
System design must be based on reviewing existing class diagrams, sequence diagrams, updated object models
that represent the internal workings and designs of the containing subsystems that exposes the services and
component specification.
The Contractor shall conduct a walkthrough of the final TDD with the Oregon Votes Project Team, and the
External QA Consultant, to validate the contents of the TDD.
The approved TDD and FDD shall constitute the complete system definition for the System. The FDD and the
TDD together shall constitute the agreement between Agency and the Contractor regarding the functionality
and operation of the System. The two documents shall be the documentation used by the Contractor during
system development along with the use cases and shall be the basis for the development of the User
Acceptance Test (UAT).

The TDD must reflect the final requirements for  Agency-accepted
System configuration and operation. Contractor DED.
shall develop this document based on outputs from  Deliverable contains
the technical design sessions conducted with the all criteria agreed-
Contractor and the Oregon Votes Project Team. upon in the DED.
The TDD must include the following components:  Agency PM approval.
Technical Design
4.2
Document (TDD)  Detailed description of System architecture.
 Entity Relationship Diagrams.
 Data Flow Diagrams.
 Data Dictionary.
 Processing controls.
 Processes to manage System installation and
configuration.
Page 23 of 148
 Data backup procedures.

 Security controls.
 Availability and resilience controls such as load
balancing, failover capabilities, and fault
tolerance.
 Technology Stack (specifying brand,
manufacturer, version), to include but not be
limited to:
o Database engine
o Operating System
o File Transfer Mechanisms
o Conversion Tools
o Development Languages
o Ancillary tools
Task 4.3 – Security Plan

Contractor shall develop and deliver a Security Plan to Agency. The Security Plan must detail how security will be
controlled during the implementation and ongoing operation of the System, and shall in all material respects
comply with the standards set forth in the most current version of the National Institute of Standards and
Technology (NIST) Special Publication 800-53 Rev. 5 (Security and Privacy Controls for Information Systems and
Organizations).

The Security Plan, at a minimum, must describe the following  Agency-accepted DED.
items related to the System:  Deliverable contains
all criteria agreed-
 Logical security controls (privacy, User access and
upon in the DED.
authentication, user permissions, etc.)
 Security features and
 Data Entry requirements for authenticating data and voter
architecture is
authenticity.
traceable to
 Voter Data Access
applicable security
Security  Backend voter registration system protection to prevent
4.3 standards specified in
Plan unauthorized access.
Exhibit B of the
 Access Control
Agreement.
 Two person verification process  Identifies
 Voter authentication conformance of
 Network security applicable Voluntary
 Auditability and monitoring Voting Systems
 Authorization procedures Guidelines.
 Cloud Security considerations.
Page 24 of 148
 Incident Detection  Agency PM approval.

 Data Backups
 Data Suppression and Virtualization
 Data transfer
 Process for Key Personnel performing critical management
or development
 System testing requirements
 Security training requirements for personnel
 Threat identification and hunting
 Vendor and staff background investigation process
 Vulnerability Scanning
 Technical security controls and security architecture
(communications, hardware, data, physical access, software,
operating system, encryption, etc.)
 Security processes (security assessments, risk assessments,
incident response, etc.)
 Discuss the security policies and technical approach to satisfy
the following:
o Network segmentation
o Perimeter security
o Application security and data sensitivity classification
o PII data elements
o Intrusion detection and management
o Monitoring and reporting
o Host hardening
o Remote access
o Encryption
o State-wide active directory services for authentication
o Interface security
o Security test procedures
o Managing network security devices
o Security patch management
o Detailed diagrams depicting all security-related devices
and subsystems and their relationships with other
systems for which they provide controls
o Secure communications over the Internet
o Enhanced user access security (including MFA)
Page 25 of 148
Task 4.4 – Disaster Recovery and Business Continuity Plan

Contractor shall develop and deliver a Disaster Recovery/Business Continuity Plan (DR/BC Plan) to Agency. The
DR/BC Plan must be developed and validated with Agency to ensure Agency is able to comply with its
obligations with respect to Election Laws, as well as industry best practices. As part of the DR/BC Plan:
 Roll-back plans must be developed and validated for use in case of System failure during turn over to
production.
 Plans must be put in place for the stand-by of key support resources during turn-over to production
activities.
 Potential go-live System failures and action points must be identified, and mitigation plans must be
developed and validated.
Contractor shall ensure key project resources are to be trained in recovery procedures.

The plan must describe how Agency and Counties  Agency-accepted
can provide information to themselves and their DED.
customers in the event of a disaster. At a minimum,  Deliverable
the plan must include the following: contains all criteria
agreed-upon in the
 Specify backup and recovery procedures, as well DED.
as disconnected operational capability to ensure  Anticipated types
that the System can continue to operate in the of disasters
event of an unexpected destruction of hardware, includes both
software, or communications through System natural and
Disaster failure, disruption of connectivity, or natural unnatural
Recovery/Business disasters.
4.4 disasters.
Continuity Plan
 Address all areas, such as arrangements for  Agency PM
(DR/BC Plan)
backup hardware or processing sites; off-site approval.
data storage; schedule for creation of backup
media; and detailed recovery procedures for all
anticipated types of disasters.
 A description of each anticipated type of disaster
shall be provided.
 Describe escalation plans that specify the
necessary points of contact and decision-making
authority at the Agency and the Oregon Votes
Steering Committee.
Task 5.0 – System Development and Configuration

Page 26 of 148

MVP August 2021 August 2022
Phase 2 December 2022 June 2023
Purpose and Objective: System development efforts shall be guided by the Deliverables of the Requirements
Development and Validation and System Design tasks. This ensures that the System is constructed consistently.
The Contractor may not initiate the System development activity until the Agency’s PM has Accepted the System
Functional and Technical Design Documents.
Contractor shall fully document each software module. This documentation must support the transfer of
knowledge to the Oregon Votes Project Team. The Contractor shall also transfer all final System Documentation
to the Agency’s PM.
Contractor shall inform its development and configurations of the System by using a series of multi-week sprints
to iteratively develop, test, and validate that development is meeting Requirements.
These sprints will be conducted using the following general format:
 One Backlog Grooming and establishing acceptance criteria.

 Sprint planning.
 Development and testing.
 Agency and County preparation of test scripts.
 The sprint demo.
Contractor shall setup a user testing and training environment for ongoing testing of the sprints, including setup
of data and User access.
 Identify and coordinate with the appropriate State and County personnel for early and continuous user
engagement and testing. This is for System development and configuration purposes.
 Conduct periodic review sessions.
 Confirm System Documentation and Deliverable updates and provide feedback on required updates.
Task 5.1 System Development and Configuration

Contractor shall develop and configure the System to reflect and satisfy the requirements outlined in the FDD and
TDD. Part of the development and configuration will be the installation of any third-party product or the
development of necessary modules.
Page 27 of 148
Additionally, the Contractor shall develop interfaces described in the Requirements and documented during the
design phase of this SOW.
The Contractor shall follow development and testing industry best practices and standards.

The report must indicate that the MVP  Agency-accepted DED.
configuration and development has  Deliverable contains all criteria
been completed and tested. The report agreed-upon in the DED.
MVP System must include validating that the  Development and configurations
Development and functional and non-functional adhere to the MVP requirements
5.1.1
Configuration Requirements for MVP have been as defined in the Detailed
Validation Report addressed, required interfaces have Requirements Traceability Matrix.
been developed, and that testing has  Configurations and functionality
validated the functionality is working align with Agency-approved To-Be
together as a system. Process Maps.
The report must indicate that the
Phase 2 configuration and
 Development and configurations
development has been completed and
adhere to the Phase 2
tested. The report must include
Phase 2 System requirements as defined in the
validating that the functional and non-
Development and Phase 2 Detailed Requirements
5.1.2 functional Requirements for MVP
Configuration Traceability Matrix.
have been addressed, required
Validation Report  Configurations and functionality
interfaces have been developed, and
align with Agency-approved To-Be
that testing has validated the
Process Maps.
functionality is working together as a
system.
Task 5.2 Periodic Reviews

During the System Development Tasks, the Contractor shall schedule periodic reviews for the Oregon Votes
Project Team and External QA Consultant to measure overall progress, status, and work products. These reviews
will be conducted by the Oregon Votes Project Team.

 Contractor attends and
5.2 Periodic Reviews No documentation required. participates in Agency’s
Periodic Reviews.
Page 28 of 148
Task 5.3 System Documentation Updates - Configuration

Once the System has been developed, the Contractor shall make updates to any of the System Documentation
(development, training, security, design, elaborated Requirements, etc.) to reflect any changes that have
occurred during the development process.

 Updates made
Documented updates to the FDD and TDD to reflect
System reference the specific
any changes to design and requirements resulting
5.3.1 Documentation Sprints that caused
from the System Development and Configuration
Updates (MVP) the update.
Task of this SOW during MVP.
 Updates made
System Documented updates to the FDD and TDD to reflect
reference the specific
Documentation any changes to design and requirements resulting
5.3.2 Sprints that caused
Updates from the System Development and Configuration
the update.
(Phase 2) Task of this SOW during Phase 2.
Task 6.0 – Data Conversion and Migration


MVP June 2021 February 2023
Phase 2 August 2023 September 2023
Purpose and Objective: Identify and ensure the relevant data existing in Agency’s legacy systems is converted
and migrated to the System.
Contractor and Agency shall identify legacy system(s) where data needs to be converted and migrated from, and
Contractor shall perform the testing and extraction activities necessary to convert the data at the time of System
go-live for both the MVP release and the Phase 2 release. Contractor shall validate the data conversion and
migration results, with assistance from Agency. Contractor shall coordinate with the Counties and provide a
mechanism that allows the Counties to validate the data conversion and migration.
Contractor shall map data from OCVR and other required legacy systems to the System; develop the tools to
migrate the data; complete the migration; produce a migration validation report; and transfer all final System
Documentation to the Agency’s PM.
Page 29 of 148
Contractor shall perform this task in multiple data conversion cycles so that data is available for the following
activities, as they occur in this Project:
 Data conversion cycles to ensure Data is ready for Sprints (Task 5.1).
 Data conversion cycle to ensure Data is ready for System Testing (Task 7.1).
 Data conversion cycle to ensure Data is ready for UAT (Task 7.2).
 Data conversion cycle to ensure Data is ready for the Mock Election (Task 7.3).
 Data conversion cycle to ensure Data is ready for MVP and Phase 2 System roll-out (Task 8).
 Provide County contact point(s).

 Provide an available OCVR Database Analyst during this Task’s Period of Performance to work with
Contractor’s Database Analyst on the following:
o Data conversion and migration planning.
o Creating processes to extract data and images from OCVR.
 Provide a data dictionary of the OCVR data structure and full data extracts.
 Manage data cleanup activities prior to conversion.
Deliverable(s) and Acceptance Criteria: All Deliverables and Acceptance Criteria are specified in the subtasks
below.
Task 6.1 – Data Migration Mapping

Contractor shall analyze the current OCVR data and develop a comprehensive data migration map. The data
migration map will be reviewed with the Oregon Votes Project Team for clarity and completeness. The data
migration map must include but is not limited to:
 Evaluation of what data will be pulled out.

 Define how the data will convert.
 Determination if or how long the System and legacy systems will run in parallel.
 Contingency plan in the event Agency must fallback to legacy system(s).
Contractor shall conduct a walkthrough of the final data migration map with the Oregon Votes Project Team and
the External QA Consultant to validate the contents.
The approved data migration map shall be the indicator for the Contractor to proceed in developing the data
migration tools.
Page 30 of 148

The Data Migration Map must reflect the final
requirements for migrating OCVR data. The Data  Agency-accepted
Migration Map must include, but is not limited to, the DED.
following components:  Deliverable contains
 Data dictionary all criteria agreed-
Data  Detailed data map of all elements of the current upon in the DED.
6.1 Migration databases  Identifies data
Map required to be
 Translation rules
migrated during MVP
 Relationship rules
and Phase 2.
 Validation rules  Agency PM approval.
 Process of migrating images (signature, applications,
documents)
Task 6.2 – Data Migration Report

The Contractor shall:
 Design and develop the tools necessary to perform the data migration according to the Data Migration
Plan.
 Convert all the new target databases to the correct format and load the required data for the testing of
the System.
 Test the migration process in a test environment.
 Validate the migration and revise as necessary to achieve a successful migration.
 Facilitate a review of the test migration process in the test environment with the Oregon Votes Project
Team.
When the Contractor completes their validation, a data migration report will be provided to the Agency’s PM as
part of the data migration validation.
The Contractor shall revise the migration based on feedback from the Oregon Votes Project Team validation
activities.
The Contractor shall design, code, and test the database migration logic. As part of the data migration activity,
the Contractor shall produce data clean-up reports based on the discovery, analysis, and testing the new target
database.
Page 31 of 148
A data migration report which summarizes the

MVP migration success. This includes but is not
limited to:
 Number of data records used for input and
number of records migrated, including:
o Voter registration records
o Number of voter registration records by
status  Agency-accepted
o Each county DED.
MVP Data
o Districts and precincts  Deliverable contains
6.2.1 Conversion
o Signatures and images all criteria agreed-
Completion Report
upon in the DED.
o Petition summary
o Street file summary
 Exceptions discovered as part of the
migration.
 Process of migrating images (signature,
applications, documents).
 Documented validation of data successfully
converted and migrated.
Phase 2 Data A data migration report which summarizes the
6.2.2 Conversion Phase 2 migration success, to include the  Agency PM approval.
Completion Report components described in Deliverable 6.2.1 above.
Task 6.3 - User Migration

The Contractor shall evaluate the existing user directory, design a new user directory, develop a process for
migrating users from the existing user directory to the new user directory, and execute the migration.
The Contractor shall migrate user account names, any user privileges, and any group assignments. Additionally,
the Contractor shall develop a mechanism for securely distributing user credentials (i.e. usernames and
passwords) for the new user accounts. This distribution mechanism must be approved by the Agency prior to
distributing the credentials.

A user migration report which
MVP User summarizes the MVP migration
6.3.1 Migration success. This report must document
Completion Report validation of successful user
migration.
Phase 2 User A user migration report which
6.3.2 Migration summarizes the Phase 2 migration  Agency PM approval.
Completion Report success. This report must document
Page 32 of 148
validation of successful user

migration.
Task 7.0 – Testing


MVP March 2022 February 2023
Phase 2 June 2023 August 2023
Purpose and Objective: Perform various types of tests to ensure the System and its components adhere to the
TDD and FDD, aligned with the Requirements.
Contractor shall perform a series of Component (Unit) and System tests and shall support Agency’s User
Acceptance Tests (UAT). This includes emphasis on testing new functionality, as well as regression testing of
already accepted functionality to ensure that changes to software have not adversely affected existing code.
Each phase of testing requires the development of a thorough Test Plan, including test cases, scripts, data
sheets, and expected results. The tests that are developed must be repeatable and must be directly traceable to
the Requirements.
System testing and UAT must be designed to demonstrate that the System satisfies the Requirements and the
Design (i.e. the Agency-accepted FDD and TDD) and must adhere to detailed test plans and test scripts. The
Oregon Votes Project Team, Contractor, and External QA Consultant all have significant roles in the testing
process. The Contractor shall thoroughly test the software itself before the Agency and County UAT teams begin
their work. For the initial release, this includes component/unit testing, system/integration testing, volume and
stress testing, performance testing, and load balancing testing prior to User Acceptance Testing. For future
releases, this will include component/unit testing, system/integration testing, and other testing as deemed
necessary by the Agency’s PM. When the Contractor test results are validated by the Agency’s PM and the
External QA Consultant, Agency will commence UAT activities. Upon the completion of the UAT, Contractor shall
assess each release’s overall readiness and a decision will be made by Agency (Go/No Go) regarding
deployment.
 Identify and coordinate with the appropriate State and County personnel for early and continuous user
engagement and usability testing, including UAT and Mock Elections, and provide results back to
Contractor.
 Perform UAT, including Mock Elections.
 Provide Agency and County Client Environments for System testing purposes.
 Coordinate State, County, and Agency Third-Party (e.g., AFB Vendor) resources and environments
required for Testing, with the exception of AAMVA.
 Review, provide feedback, and validate Contractor’s UAT Test Plan and scripts.
Page 33 of 148
 Provide additional scenarios for inclusion into Contractor’s UAT Plan and scripts.
 Confirm required System Documentation Updates as a result of Testing activities.
below.
Task 7.1 – System Testing

During both the MVP and Phase 2, the Contractor shall conduct and perform various Usability, Unit, Subsystem,
and Integrated System qualification tests of all System functionality. The Contractor shall be responsible for
generating the test data and test cases to be used for its own System qualification test.
The Contractor shall develop the System using a structured system life cycle development methodology that
includes the following types of testing activities:
Usability Testing
This type of testing is used with early releases for the purpose of delivering components of the System before
they are ready for thorough inspection to allow the Agency and Counties the opportunity to provide feedback
and help drive development. Defects are expected to occur at this stage, and Contractor shall record and
communicate issues discovered.
Unit Testing
This type of test is used to validate that an individual program module or script functions correctly. Each
System module that has been developed shall be tested to ensure that all module functionality is working
properly. If a module interacts with other modules, the interfaces between the modules are ‘stubbed’ out or
removed so that only the module itself is tested in isolation. These tests are generally informal tests
conducted and documented by a developer.
Subsystem Integration Testing
This type of test ensures that small groupings of modules are working properly. While full System functionality
is not yet tested in this phase, groups of modules that work together shall be isolated and tested to ensure
that key activities work properly from end to end. This type of testing is generally performed by developers in
the development environment. This is expected by the Oregon Votes Project Team to be the first phase of
testing where all test planning and documentation activities listed in the Test Plan shall occur.
End-to-End Testing
Page 34 of 148
This phase of testing involves testing the System’s functionality end-to-end, including testing all interfaces to
internal and external systems that interact with the System. This test must cover System performance,
volume, stress, and load balance testing, and must focus on verifying that the System’s functionality conforms
to the Functional and Non-Functional Requirements that were defined for the System. System documentation
must be reviewed to ensure that it encompasses a sufficient scope and that it was developed with sufficient
quality. This test must be conducted in an environment synchronized with the target Production environment
and is conducted by the Contractor testing team, which is independent of the development team. Contractor
shall ensure through this testing phase that the conversion and use of legacy system data does not generate
any errors. The Contractor shall perform end-to-end testing until all Level 1 (Catastrophic) and Level 2 (Major)
Defects, as determined by the Agency’s PM, have been remediated within the System (e.g., missing
functionality, computational errors).
Regression Testing
The Contractor shall be responsible for regression testing for the System. Regression Testing encompasses the
re-running of previously completed test cases after new functionality or bug fixes have been added to the
System. The Contractor is expected, through Regression Testing, to ensure that any changes made to the
System have not broken previously working System functionality.


Prepared for each phase of testing  Agency-accepted DED.
identified above for both MVP and Phase  Deliverable contains all
2, each test plan must include: criteria agreed-upon in the
 Test cases DED.
7.1.1 System Test Plans
 System Test Plans identify
 Test scripts
tests to be completed during
 Data sheets
MVP and Phase 2.
 Expected results  Agency PM approval.
Documentation of the various MVP test  Agency-accepted DED.
results from each type of the system test,  Deliverable contains all
including: criteria agreed-upon in the
MVP System Test  Usability Tests DED.
7.1.2  Unit Tests
Results  All test cases render the
 Subsystem Integration Tests expected result or pass after
 End-to-End Tests remediation and re-testing.
 Regression Tests  Agency PM approval.
 All test cases render the
Documentation of the various test results
expected result or pass after
7.1.3 Phase 2 Test Results from each type of system test conducted
remediation and re-testing.
during Phase 2.
Page 35 of 148
Task 7.2 – User Acceptance Testing (UAT)

The Contractor shall be responsible for providing support to the Oregon Votes Project Team during the planning
and execution of UAT for both the MVP and Phase 2 releases of the System. Contractor support shall involve
assistance with the following activities:
 Plan and set up a UAT environment.

 Provide an efficient approach to testing that maximizes parallel and overlapping test activities.
 Explain how development has interpreted Requirements.
 Communicate information about problems encountered during earlier test phases.
 Respond to and fix reported defects.
 Determine workarounds to be used during test scenario execution.
 Provide information concerning the content of code builds during test execution.
 Track details and provide summary reporting on testing plans, progress, issues, and interim
results during test execution.
The following activities have been identified as necessary to this subtask:
UAT Testing Environment Setup
Contractor shall:
 Prepare, install, and configure the System in the UAT environment.
 Coordinate all UAT environment setup activities with the Oregon Votes Project Team.
 Ensure the System is properly integrated and that it is properly interfacing with all required
existing external systems.
 Setup, installation, and integration of the System in all locations necessary to complete UAT
activities.
 Maintain responsibility for System operations throughout UAT.
UAT Testing Support
Once the key function walkthrough has been completed with no errors, Contractor shall make the System
available to the Agency and County UAT testers, who will then conduct a formal UAT of the System.
Contractor shall:
 Develop core functional UAT test scripts and UAT tester training materials with approval of the Agency’s
PM and External QA Consultant. Test scripts must thoroughly test each functional requirement.
 Develop, maintain, and refresh the UAT test environment (including database and loaded test cards).
This shall be a separate environment from the production environment.
 Provide System training for the UAT testers.
 Provide real-time support of UAT testers.
 Coordinate UAT in cooperation with the Oregon Votes Project Team.
 Provide an application for the capture, reporting, and tracking of errors identified during UAT.
 Document UAT Results.
 Fix any errors identified as a result of UAT.
Page 36 of 148
Contractor may be asked during the UAT to incorporate additional test scenarios, documenting their inclusion
and test results. During testing, Contractor shall maintain the UAT environment and the UAT tools, including test
cards and base dataset.
Agency and Counties anticipate testing occurring in two rounds for both MVP and Phase 2; however,
acknowledge that more may be necessary depending on the results of UAT. The first round should be used to
identify errors. The second and subsequent rounds should be used to validate that all errors have been fixed.

Documentation of all the test results, including any errors  Agency-accepted

and resolutions identified as a part of the UAT test. The DED.
UAT Report must summarize the UAT results, and whether  Deliverable contains
the UAT objectives were met. At a minimum, it the UAT all criteria agreed-
MVP UAT Report must cover the below:
7.2.1 upon in the DED.
Report  Achievement of UAT objectives.  All UAT test issues
 Test execution results by test cycle. are resolved for the
 Test execution statistics and trends. MVP.
 A plan to address any UAT test issues still unresolved.  Agency PM approval.
 All UAT test issues

Phase 2 All documentation required for the MVPUAT Report but are resolved for
7.2.2
UAT Report delivered for Phase 2 UAT testing results. Phase 2 scripts.
Task 7.3 – End-to-End Mock Election

Contractor shall conduct a Mock Election exercise with Agency and Counties following the MVP release of the
System. The Mock Election is an end-to-end testing of the Oregon Election process. Agency anticipates possible
scenarios being a general Mock Election and another scenario being a Mock Primary Election, based on
augmented real election data.
To support this effort, Contractor shall:
 Coordinate the details with Agency and update the System Test Plans.
 Ensure an Environment is set up to facilitate the Mock Election.
 Conduct the Mock Election.

Page 37 of 148
Summary of results, and  Agency-accepted DED.

documentation of all mock  Deliverable contains all criteria
election results, including any agreed-upon in the DED.
7.3 Mock Election Results
errors and resolutions  All issues identified are resolved, or
identified as a part of the exceptions/issues are approved by the
scenarios. Agency PM.
Task 7.4 – Load and Stress Testing

Load and stress testing include high availability and disaster recovery testing.
The Contractor shall be responsible for load and stress testing for the System as well as validation of fault
tolerance and planned disaster recovery capabilities of the System. Load and stress testing validate the System’s
ability to continue operations under maximum loads and stressed conditions. The Contractor is expected to load
the System to a minimum of 125% of the number of planned users and volume of transactions using automated
loading tools. The Contractor is also responsible to conduct a complete run through of the System’s fault
tolerance and disaster recovery technologies and processes.
Contractor shall prepare a Load and Stress Test Report documenting all the test results including any errors and
resolutions identified as a part of the load and stress test.


The report must summarize the MVP load
and stress test results and whether the  Agency-accepted DED.
objectives were met. At a minimum, the  Deliverable contains all
report must cover: criteria agreed-upon in the
 Achievement of load and stress test DED.
objectives.  All MVP load and stress test
MVP Load and  Successful failover and failback testing. objectives are achieved.
 Test execution results indicating the  MVP test execution results
7.4.1 Stress Test
responsiveness of the System at low indicate the responsiveness of
Report
the System adheres to Agency
and peak load times.
requirements.
 Test execution results indicating the  All MVP test issues are
responsiveness of the database(s) at resolved, or exceptions/issues
low and peak load times. are otherwise approved by
 A plan to address any test issues still the Agency PM.
unresolved.
Page 38 of 148
 All Phase 2 load and stress

test objectives are achieved.
 Phase 2 test execution results
The Phase 2 report must summarize the
indicate the responsiveness of
Phase 2 Load Phase 2 load and stress test results, and
the System adheres to Agency
7.4.2 and Stress Test document the same information required in
requirements.
Report the MVP load and stress test results but for
 All Phase 2 test issues are
Phase 2 components.
resolved, or exceptions/issues
are otherwise approved by
the Agency PM.
Task 7.5 – System Documentation Updates from Testing

Once Agency has Accepted all System testing Tasks with respect to each of the MVP release and the Phase 2 release of the
System, the Contractor shall make updates to any of the System Documentation (development, training, security,
design, requirements, etc.) to reflect any changes that have occurred during the testing process. The Contractor
shall also transfer all final Documentation to the Agency’s PM.

System Updates to the FDD and TDD based on MVP  Updates made are
7.5.1 Documentation testing results and any changes made that traceable to Testing results.
Updates (MVP) were necessary to resolve testing issues.  Agency PM approval.
System Updates to the FDD and TDD based on Phase 2  Updates made are
7.5.2 Documentation testing results and any changes made that traceable to Testing results.
Updates (Phase 2) were necessary to resolve testing issues.  Agency PM approval.
Task 7.6 – System Operations Documentation

The Contractor shall prepare and submit System Operations Documentation that describes all required System
operational activities and provides guidance on System Maintenance and Enhancement practices, tools, and
approaches, and provide updates to the System Operations Documentation at the end of Phase 2 activities.
The Contractor shall also provide any additional documentation, such as the Commercial off the Shelf (COTS)
software user manual(s), if applicable.

Page 39 of 148

This documentation must encompass System  Agency-accepted
Functionality from a County User’s perspective, an DED.
Agency User’s perspective, and from an information  Deliverable contains
technology and System operations perspective. These all criteria agreed-
manuals must include, but not necessarily be limited upon in the DED.
to, the types of information below:  Agency PM approval.
 A description of how to use the System based on
User roles and responsibilities.
 A list of prebuilt reports and their descriptions.
 A description of all screens and how they are
interrelated.
 A description of all help and navigation functions
and how to use them.
 A complete list of error messages, their
descriptions, and how to resolve the errors.
 A list of all included System Documentation and
Systems its use.
7.6.1 Operations  How to troubleshoot common System problems.
Documentation  A description of the key data tables, elements,
and their contents.
 How to perform System maintenance functions
like data backup and recovery, run batch
processes (if applicable), perform data cleanup,
and Administer User accounts and permissions.
 How to troubleshoot common System problems.
 A listing of all logs and how to interpret them.
 Key System capacity management considerations.
 Key security management functionality.
 Contact information for receiving support.
 Where to find disaster recovery and business
continuity information related to the System.
 A listing of System interfaces and how to
troubleshoot communications problems.
 File descriptions.
 System and Environment configuration baseline.
System
Operations Updates to the System Operations Documentation, as
7.6.2 Documentation described in Deliverable 7.6.1 above, based on System  Agency PM approval.
Updates changes made resulting from Phase 2 testing results.
(Phase 2)
Task 8.0 – MVP and Phase 2 System Implementation

Page 40 of 148

MVP October 2021 February 2023
Phase 2 August 2023 September 2023
Purpose and Objective: The purpose of this Task is to deploy the System for the intended business purpose.
Contractor shall manage the implementation and deployment of the System.
below.
Task 8.1 – Interface Development

For each System interface identified in Schedule 9 of this Transaction Document, Contractor shall provide APIs or
other methods for the System to provide data to or receive data from the integrated application. As
appropriate, Contractor shall implement the System to provide the required functionality, including working
directly with the interfacing application to design, develop, and test direct point-to-point interfaces. Contractor
shall additionally support Agency testing of all data exchanges.
The ICD must provide a record of  Agency-accepted DED.

all interface information, including  Deliverable contains all criteria
but not limited to: agreed-upon in the DED.
Interface Control  Drawings  Documentation demonstrates that
8.1.1
Document (ICD) interfaces comply with the Detailed
 Diagrams
Requirements Traceability Matrix
 Tables
(Deliverable 3.1).
 Textual information  Agency PM approval.
 Documentation demonstrates that

Updates to the approved ICD, or
interfaces comply with the Detailed
ICD Updates written confirmation from
8.1.2 Requirements Traceability Matrix
(Phase 2) Contractor that no updates are
(Deliverable 3.2).
needed.
This report must document and
validate that the MVP and its
MVP Interface agreed-upon in the DED.
8.1.3 required interfaces are
Completion Report  The System passes MVP Testing
functioning per the design and
described in Task 7.1.
requirements.
Page 41 of 148
This report must document and

validate that the System and its  System passes Phase 2 Testing
Phase 2 Interface
8.1.4 required interfaces are described in Task 7.1.
Completion Report
functioning per the design and  Agency PM approval.
requirements.
Task 8.2 – Data Conversion and Synchronization

To help ensure that the Contractor and the Oregon Votes Project Team fully understand the extent of the work
needed for data migration, a detailed study of migration issues and requirements (see Task 6 - Data Conversion
and Migrations) shall be required of the Contractor and included in the project plan.
The data conversion study must include:
 Reviewing conversion analysis with the Oregon Votes Project Team and preparing a detailed data
conversion plan (addressing manual and electronic data).
 Defining strategies for verifying and/or correcting existing data.
 Developing data conversion scripts and test data conversion scripts.
In this Task, Contractor shall address data migration issues and establish a plan to ensure the validation of all
conversion routines and the accuracy and completeness of all data.
For this task to be successful, the Contractor shall ensure the following:
 Data conversion is planned early in the Project.

 Process in place for validating conversion success and mitigating conversion failures.
 Plan for data conversion and synchronization issues during deployment.
 Validation routines exist to ensure conversion success.
 Conversion checklists defined.
 Conversion resources defined.
 Contractor support during conversion communicated.
 Restart and roll-back scenarios in case of conversion failure defined.
 Estimated conversion effort defined.
 Contingency in case of conversion problems defined.
Contractor shall perform continued data conversion and synchronization between the legacy systems and the
System during both Phases 1 and 2, until full implementation of the System is achieved.
Page 42 of 148
A field-by-field mapping (including how the

values shall be converted) from the legacy
systems to the System, including the below.
 Any assumptions or proposed calculations
involved in the conversion.
 Default values for required fields that do
not exist in the legacy system(s) or a
method to allow for missing data until all
participants are on the System.
 Methods for handling anomalies in the
data between the legacy system and the
System (data elements with incompatible
length and/or type between the systems,  Agency-accepted
or data elements with stricter edit DED.
Data Conversion and requirements in the System that fail those  Deliverable contains
8.2 edits in the legacy system).
Synchronization Plan all criteria agreed-
 How data elements that have been upon in the DED.
assigned default values by the automated  Agency PM approval.
conversion procedures shall be populated
with actual data once automated
conversion is complete for a site.
 Detail of any data “clean up” procedures
in the individual Counties that can
effectively improve the conversion effort.
 Possible exceptions to full conversion of
the databases.
 Exception reports that will be produced
by the conversion programs and provide
for a fully reviewable conversion of data
files.
Task 8.3 – System Deployment

During both MVP and Phase 2, the Contractor shall be responsible for the operation of the System and assisting
Oregon Votes Project Team with the implementation of the Help Desk capabilities to support the System. Before
deployment can begin, the Contractor shall ensure that the following activities have taken place:
 The System’s Deployment Plan is fully developed, documented, and approved and includes the specific
time frame and activities associated with the full roll-out of the System.
 All critical resources have been identified and are available to support deployment activities.
 Critical or new technologies have been fully tested and key resources identified to provide needed
support.
 Contingency plans are in place to deal with implementation issues that may arise.
 A governance structure and Communication Plan has been developed, documented, and approved
which defines the implementation decision process and GO/NO GO events.
Page 43 of 148
 Communications have been provided to stakeholders informing them of the implementation process
and status has been developed and documented.
The deployment plan must document the
 Deliverable contains all
System Deployment specific activities and timeframes that are
8.3.1 criteria agreed-upon in
Plan required to ensure a full and successful roll-
the DED.
out of the MVP and Phase 2 System.
Contractor shall review MVP Mock Election

System  Written notes provided to
Results and the System Deployment Plan
Implementation Agency PM after the
8.3.2 with Agency. Contractor shall document
Checkpoint Meeting meeting.
questions, issues, and action items
Notes  Agency PM approval.
resulting from the meeting.
Contractor shall provide inputs into

8.3.3 Agency Roll-Out Plan Agency’s roll-out plan for both the MVP as  Agency PM approval.
well as the Phase 2 System.
criteria agreed-upon in
the DED.
 Agency receives the
Contractor shall provide a Deployment report information with
Report assessing the progress of the the Bi-Weekly Project
deployment of the MVP. Deployment Status Report.
MVP Deployment
8.3.4 Reports must be made part of the Bi-  The report provides
Report
Weekly Project Status Report during the progress, issues, and
period of performance for the deployment remediation efforts in
task. progress.
 The report documents
resolved issues and a
resolution summary for
each.
Activity to be documented in the  System’s Production is
8.3.5 MVP in Production
Deployment Report. accessible by Users.
Page 44 of 148
 Disaster recovery
procedures executed
successfully.
 Thirty continuous days
without Criticality 1 or
Criticality 2 issues,
including interface
transactions.
 Agency receives the
report information with
the Bi-Weekly Project
Contractor shall provide a Deployment Status Report.
Report assessing the progress of the  The report provides
deployment of the Phase 2 System. progress, issues, and
Phase 2 Deployment
8.3.6 Deployment Reports must be made part of remediation efforts in
Report
the Bi-Weekly Project Status Report during progress.
the period of performance for the  The report documents
deployment task. resolved issues and a
resolution summary for
each.
 System’s Production is
accessible by Users.
 Disaster recovery
procedures executed
Phase 2 System in Activity to be documented in the successfully.
8.3.7
Production Deployment Report.  Thirty continuous days
without Criticality 1 or
Criticality 2 issues,
including interface
transactions.
Task 8.4 – System Documentation Updates

Once the System has been deployed, Contractor shall make updates to any of the System Documentation
(operations, training, security, design, requirements, etc.) to reflect any changes that have occurred during the
deployment process. The Contractor shall also transfer all final Documentation to the Agency’s PM.
Contractor shall conduct a review with the Oregon Votes Project Team and identify any documentation that
shall be updated as a result of changes. Contractor shall update the documentation and provide it to the
Agency’s PM for review and Acceptance.
The Contractor shall also transfer all agreed-to and finalized documentation to the Agency’s PM.
Page 45 of 148
Acceptance
No. Deliverable Description
Criteria
The following documents are some of the critical
documents that are to be updated and provided to the
Agency’s PM at the completion of MVP:
 Functional Design Document

Updated System
 Technical Design Document  Agency PM
8.4.1 Documentation
 Security Plan approval.
(MVP)
 Disaster Recovery Plan
 Capacity Plan
 Post Configuration Report
 Training Materials
The following documents are some of the critical
documents that are to be updated and provided to the
Agency’s PM at the completion of Phase 2:
 Functional Design Document

Updated System
 Technical Design Document  Agency PM
8.4.2 Documentation
 Security Plan approval.
(Phase 2)
 Disaster Recovery Plan
 Capacity Plan
 Post Configuration Report
 Training Materials
Task 8.5 – Incident Remediation and Software Warranty Period

The Contractor shall be responsible for fixing any errors that occur during the deployment during both MVP and
Phase 2. Once a new release has been developed, the Contractor shall perform regression testing on the release
and receive Agency’s PM approval before submitting the release into production.
At the completion of System Implementation, the Contractor, External QA Consultant, and the Oregon Votes
Project Team shall conduct a System Implementation checkpoint meeting to assess System performance and
status. After this meeting, Oregon Votes Project Team, with input from the Oregon Votes Steering Committee
shall determine whether the project can continue into the Maintenance and Support phase. Notice will be
provided by the Agency’s PM.
Page 46 of 148
All incidents and defects that occur during

the Post-Implementation Warranty Period
which are part of the Solution scope (and
under Warranty agreement) shall be
documented and communicated with the  Agency-accepted DED.
Oregon Votes Project Team within a  Deliverable contains all
System Incident
8.5.1 reasonable, agreed upon time frame, on a criteria agreed-upon in
Reports (Warranty)
regular basis. The incident report shall the DED.
contain the severity of the incident, a  Agency PM approval.
description of the incident, incident
resolution status, and the proposed course
of action for remedying all open incidents.
All corrective maintenance requests which

are part of the System that occur during
the Post-Implementation Warranty Period
shall be documented and communicated  Agency-accepted DED.
with the Oregon Votes Project Team  Deliverable contains all
Corrective
8.5.2 weekly. The maintenance report shall criteria agreed-upon in
Maintenance Reports
contain the description of the maintenance the DED.
request, resolution status, and the  Agency PM approval.
proposed course of action for remedying all
open maintenance requests.
Task 9.0 – Training


MVP February 2022 February 2023
Phase 2 July 2023 July 2023
Purpose and Objective: Effective training that must provide Users with the required skills to use the System,
including the facilitation of any organizational/business process changes.
The Contractor shall be responsible for the development of User training curricula, schedules, training materials,
and training evaluation materials. The Contractor shall be responsible for the setup and maintenance of an
online training environment that allows trainees to access the System. Contractor may fulfill its obligations
under the previous sentence by making the test environment available for training. The Contractor shall also be
responsible for conducting trainings and for managing all training planning and logistics. Trainings will occur
virtually and may also occur as an in-person, face-to-face, format if required by Agency and is not during any
pandemic-related shutdown orders. Agency will provide names and contact info of users to be trained.
Contractor shall provide “train the trainer” sessions.
Page 47 of 148
Contractor shall develop User training in alignment with the requirements defined in the Training Plan.
The Contractor shall be responsible for coordinating training efforts with voter registration and election subject
matter experts (SMEs), identified by the Oregon Votes Project Team, who will provide policy and practice
support to the Contractor and be present at the training sessions to provide input, as necessary, regarding
practice and policy questions or implications.
 Identify specific individuals to be trained.

 Identify specific SMEs and coordinate their attendance at training sessions.
 Coordinate training dates, times, and places.
 Produce printed Training Materials, if required by Agency.
 Reserve physical facilities for in-person trainings, if any.
 Provide A/V Equipment for in-person trainings.
below.
Task 9.1 – Training Plan

Contractor shall develop and deliver a Training Plan to the Agency and the Counties. All Users will require some
level of training. Contractor shall incorporate into the Training specific changes to the Contractor Intellectual
Property that Contractor implemented in response to the Requirements or to Oregon-specific voter registration
policies and procedures.
The Training Plan shall include, without limitation, the following categories training:
 Train the trainer
 Agency/ESC/Super Users
 County-wide Stakeholder training
Contractor shall detail in the Training Plan:
 the curriculum and materials development;

 training-of-trainers development;
 training roll-out schedule;
 materials production including computer-based training; and
 the training schedule, including number of days and preliminary agendas for the training.
Contractor shall identify the proposed training staff in the Training Plan.
Page 48 of 148

The plan must describe the types of training and  Agency-accepted
the audience for each; provide a description of DED.
training materials; provide a description of  Deliverable contains
training methodology, including a detailed list of all criteria agreed-
topics to be covered for each type of training; upon in the DED.
and describe the methodology for evaluation of  Agency PM approval.
training effectiveness. The plan must provide an
overview of tools and materials to be employed
9.1.1 Training Plan in the training including workbooks, handouts,
evaluative materials, and a training system (if
employed). The types of training must include,
at a minimum:
 County Users
 Agency Users
 System Administrator
 “Train- the-Trainer”
The training materials must include items used
to conduct the training sessions for the System
which shall ensure that training objectives are  Agency-accepted
met. These materials can include presentations, DED.
demonstrations, activities, handouts, and other  Deliverable contains
required documentation. These materials shall all criteria agreed-
also include training plans, evaluation materials, upon in the DED.
and training maintenance and support plans. An  Approval from
9.1.2 Training Materials
electronic copy of all training materials shall be Oregon Votes County
provided to the Agency’s PM. Training materials Subcommittee that
must be documented for each of the training Training Materials
types described in the training plan. System addresses County
Training Materials should be incorporated into training needs.
the System, such as help files or webinars, and  Agency PM approval.
be accessible to users. Each individual trainee
should receive a copy of the training materials.
Task 9.2 – User Training

Contractor shall deliver the training developed in the Training Plan, using an approach that enables Users to
effectively use the System. Trainings must be developed into at least the following two categories:
1. Train-the-trainer; and
2. Training for general end-users.
Page 49 of 148
The System training, in addition to focusing on the navigation and use of the System, must also focus on how the
System is integrated into the day-to-day work of Users, including new business processes and workflows that
the System will support.
After each training event, the Contractor shall provide the Agency’s PM with documented evidence of each
trainee’s competence to operate the System and integrate its support into their day-to-day work.
Training must be provided “just in time” prior to deployment and must comprehensively address all System
operations as well as security considerations. Following the initial delivery of each training Contractor shall post
the training material available online for User access.


 Recordings provided to Agency in a
Video recording of each training session portable media file and available
conducted, to capture the following online in a format compatible with
elements: Agency equipment, such as an mp4.
 Screenshare of the instructor’s  Includes visuals of the trainer’s
User Training
9.2 windows within the System as the screen while providing the training
Recordings
training session is occurring. within the System application.
 Audio of the instructor throughout  Includes audio of the Contractor’s
the course of the training session, trainer that aligns with the screen
synched with the screenshare. being shared.
Task 9.3 – User Documentation

Contractor shall provide User Documentation and ensure it is updated during the Maintenance and Support
phase to reflect System changes and enhancements.
This user documentation must be Oregon specific outlining how to perform functions and processes on the
System for Oregon. The Contractor shall provide updates to the user documentation during the Maintenance
and Support portion of the contract reflecting applicable changes based on new releases, System
enhancements, and System updates.
Page 50 of 148

Contractor shall provide electronic user manuals
and documentation that is specific to Oregon  User guides and manuals
are not pre-canned or
business processes, and to all configurations and
customizations to the application that were generic.
made per the Agency’s needs and Requirements  Agency-accepted DED.
and were delivered by the vendor.  Deliverable contains all
criteria agreed-upon in the
User
9.3.1 DED.
Documentation At a minimum, User manuals must include
System process instruction in the following  Approval from the Oregon
Votes County
documents or sections:
Subcommittee that User
 Agency Administrator manual
Documentation will meet
 Agency User Manual
County’s needs.
 County Administrator Manual
 County User Manual
 User guides and manuals
are not pre-canned or
generic.
Updated User
Contractor shall update the User Documentation criteria agreed-upon in the
Documentation
9.3.2 following Implementation of the Phase 2 release DED.
following Phase
of the System.  Approval from the Oregon
2
Votes County
Subcommittee that User
Documentation will meet
County’s needs.
Task 10.0 – System Maintenance and Support

MVP March 2023 September 2023
Until Transaction Document Expiration Date or

Phase 2 September 2023 termination (see Section 2.1 of this Transaction
Document).
Purpose and Objective: The purpose of this task is to ensure the System is maintained to meet the
Requirements and is supported to enable the Agency to use the System.
Page 51 of 148
The Contractor shall provide a Service Manager for the System and conduct meetings with Agency and the
Counties on an agreed upon frequency.
Agency will provide Tier 1 Support beginning at the completion of the MVP release System Stabilization Period.
Tier 1 Support will have two components:
 Contractor shall provide issue intake via the Golden Button and emails routed (or provided) to Agency
Tier 1 Support. This will not include a live person call-in number.
 Agency is responsible for tracking and closing issues with the stakeholders.
 Agency will provide a Tier 1 Support person who will handle live in-person triage (via email, Golden
Button, or call-in) with the County users, as needed. Escalations from the Agency Tier 1 to the
Contractor Tier 2 will be part of established escalation procedures.
Agency Responsibilities: Contractor shall perform all direct HelpDesk Services to county and state users; and
provide all Deliverables required of this Task. To that end, Agency will:
 Report System issues to Contractor.

 Upon Contractor’s request, provide clarification on submitted tickets.
 Track and close stakeholder-related concerns via Agency HelpDesk systems.
 Provide Tier 1 Support to Counties as of MVP release.
below.
Task 10.1 – MVP Pre-Implementation Support Services

Contractor shall provide Pre-Implementation Support Services to Agency and Counties during UAT, Mock
Elections, and through the period that ends on the completion of the System Stabilization Period for the MVP
release. Contractor shall develop a Pre-Implementation Support Services that indicates how support will be
provided and how escalated incidents are resolved. The plan must include a proposed organizational structure,
service level commitments related to the resolution of logged incidents (based on issue priority or severity), and
metric reporting for monitoring the System and Pre-Implementation Support Services performance. The plan
must be consistent with Agency’s Project requirements and format, with inputs from the Oregon Votes Project
Team and the External QA Consultant.
Response times for System issues submitted by Agency will be in accordance with the Service Level Response
Times for Criticality levels 1 thru 3, as defined in Part B of Schedule 2.
Page 52 of 148
The plan must indicate how support is provided and

how escalated incidents are resolved. The plan must
 Agency-accepted
include a proposed organizational structure, service
Pre- DED.
level commitments related to the resolution of logged
Implementation  Deliverable contains
10.1.1 incidents (based on issue priority or severity), and
Support all criteria agreed-
metrics reporting for monitoring the System and Pre-
Services Plan upon in the DED.
Implementation Support Services performance. The
plan must also include the process of providing
weekly reports to Agency’s PM.
Contractor shall respond to all tickets based on their  Resolutions and

criticality levels and resolve the issues. If the issue is explanations
Monthly Ticket
10.1.2 related in part or in whole to User error, then provided to Agency
Resolutions
Contractor shall provide an explanation on how to PM in writing (email
avoid the User error in the future. acceptable).
Task 10.2 – Application, Operations, and Service Level Monitoring and Management; Application
Maintenance.
Contractor shall provide the following Services after Agency’s Acceptance of the Phase 2 System roll-out.
Contractor shall provide support Services and deliver two monthly reports:
1. Application monitoring, operations, and service levels – to be documented in the Monthly Operations
and Monitoring Reports; and
2. Application maintenance – to be documented in the Monthly Application Support services Report.
Application Monitoring, Operations, and Service Levels:
The Contractor shall provide application monitoring and management services. These services shall include the
following:
 Monitoring and managing all licensed software, third-party products, and interfaces related to the
System providing daily reports of transactions between external systems.
 Provide and support multiple environments that will include (but not be limited to) UAT and Production,
keeping them synchronized on a regular basis.
 Proactively and reactively notifying the Agency’s Authorized Representative of issues, incidents, or
problems found that affect or may affect the System and of any required intervention to avoid or
resolve the issue, incident, or problem.
Contractor shall report monthly on application monitoring and management, including the tracking and
reporting of any issues.
Contractor shall provide operations management services. These services include the following:
Page 53 of 148
 Monitoring scheduled operations jobs to ensure scheduled tasks start and process without error.
 Detection of abnormal conditions or alarms.
 Logging of failed operations jobs and corrective action taken.
 Restarting operations jobs as required.
 Documenting and reporting operations job issues.
 Adding and removing operations jobs.
Contractor shall report monthly on operations management services, including the tracking and reporting of any
issues.
Contractor shall provide maintenance and manage operations of the System to include software faults that are
not already documented and accepted as part of the original development effort. All incidents that occur as part
of ongoing operations shall be addressed and resolved within a reasonable time frame as per the negotiated
Service Level Agreement (SLA) provided in Schedule 2.
Contractor shall conduct service level monitoring and reporting that includes, at a minimum:
 Ongoing monitoring of Contractor adherence to service levels.

 Any issues that could impact an agreed-upon service level.
 Resolution of any root-causes impacting Contractor’s ability to meet agreed-upon service levels.
 Providing monthly statistics and management reports to Agency Authorized Representative on service
level attainment.
In addition to the reports under this Task, Contractor shall ensure Agency has access to monitor and review
service level attainment for the System.
Application Maintenance:
All changes and fixes shall be implemented based on a mutually agreed upon schedule. All changes shall go
through all phases of testing as outlined in the Test Plan. The test results shall be documented and provided to
Agency for approval before a decision is made to put the new release into production. All relevant System
Documentation shall be updated and provided to Agency and Counties after any System changes, including after
the completion of any Enhancements.
Contractor shall manage and implement licensed software (i.e., software that is Contractor Intellectual Property-
as modified pursuant to this Transaction Document) and third-party product revisions. For each new release,
Contractor shall:
 install the release to all relevant environments with Agency’s approval to sync all environments as
necessary;
 perform integration testing of releases to validate the expected functionality;
 perform regression tests in a non-production environment that is sufficient to ensure the release does
not negatively affect current functionality;
 notify Agency and the Counties to conduct UAT testing that will include Agency and Counties as
necessary, with support from the Contractor;
 resolve problems/incidents found in regression or integration testing;
Page 54 of 148
 provide a list of changes that may require updates to the training materials; and
 make necessary changes to the User Documentation.
Contractor shall establish a process for managing configuration and technology changes made to licensed
software and third-party products, including:
 Configuration and technology change management procedures including submission, analysis,

prioritization, and approval of requests.
 Configuration and technology change approval meetings, as needed.
 Execution of configuration and technology change(s).
 Validation of configuration and technology change(s).
The Contractor shall provide configuration and technology change management services including:
 ongoing management, including project plans and transition plan;

 reporting to Agency on change management;
 developing a production change schedule that is agreed upon by the Agency;
 testing all changes to licensed software prior to moving them to production;
 testing application enhancements, error corrections, upgrades and other revisions; and
 developing test scripts and test data as needed.
Contractor shall report monthly on configuration and technology change management, including the tracking
and reporting of any issues.

The report must be provided monthly and
criteria agreed-upon in
Monthly include:
the DED.
Operations and  all issues and problems that occurred during
10.2.1  Reports provide
Monitoring the month; and
resolution details for
Reports  detail the service level adherence of the
issues that occurred.
System, as documented in Schedule 2.
 Agency receives each
report on a monthly basis.
 The maintenance report shall contain the
description of each maintenance request,
resolution status, and the proposed course
Monthly criteria agreed-upon in
of action for remedying all open
Application the DED.
10.2.2 maintenance requests, including estimated
Support  Reports demonstrate
completion of each open maintenance
Services Report verifiable progress on
request.
unresolved maintenance
 The reports must contain the description of
requests.
each Enhancement request, progress, and
Page 55 of 148
the test results and outcome of each  Agency receives each

request. report on a monthly basis.
 The report must document all configuration
and changes made to the System. If
applicable, the report must notify the
Agency if no changes occurred during the
previous month.
 Contractor provides updated
Documentation in response to any changes
to the System made during the month.
Task 11.0 ─ Hosting Services

Period of Performance: Starting March 2022 and ending upon the Transaction Document Expiration Date or
termination (see Section 2.1 of this Transaction Document).
Purpose and Objectives: The purpose of this Task is to ensure the hosting arrangement satisfies the System
Requirements and the Hosting Services Requirements set forth in Exhibit B to the Agreement.
Contractor shall establish, manage, and maintain the Hosting Services for the System.
below.
Task 11.1 – Hosting Services Delivery Document

The Contractor shall develop, maintain, and update a Hosting Services Delivery document.

The Hosting Services Delivery document must
address the Contractor’s approach to the following:
 Transition of Licensed Software from
responsibility of Contractor project
implementation team to the support team  Agency-accepted
providing the hosted services. DED.
Hosting Services  Operations and administration.  Deliverable contains
11.1
Delivery Plan all criteria agreed-
 Capacity planning and management, including:
upon in the DED.
o Storage, network, and processing
capabilities
o Monitoring performance
 Management of servers; including:
o Monitoring
Page 56 of 148
o Updating
o Optimizing performance
 Maintaining service levels.
 Defining and developing alerts (network latency
alert, saturation alert, etc.)
 Service level monitoring and reporting,
including:
o Alerts
o Service metrics
o Monitoring tools
o Service request tracking
o Audits
o Processes for communicating scheduled
outages
 Maintaining security, including:
o Physical security
o Logical security
o Periodic vulnerability testing
 Preventative maintenance, including
technology refreshes.
 Defining procedures for backups and restores,
including:
o Frequency
o Method
o Validation
o Defining restore checkpoints
 Providing business continuity and disaster
recovery services.
Task 11.2 – Hosting Service Reports

Throughout the Term of the Transaction Document, Contractor shall provide Hosting Services. The Contractor
shall:
 operate the licensed software and manage the Hosting Services on a 24x7x365 basis;
 provide Agency and Counties with access to the licensed software and Hosting Services over a pair of
dedicated network connections from the hosting environment on a 24x7x365 basis;
 provide, monitor, and maintain Hosting Services hardware, software, and communications
infrastructure, including:
o physical infrastructure for data center (e.g., facility, environment, power);
o shared networking and application infrastructure;
o computer systems, network equipment, and Contractor WAN;
Page 57 of 148
 provide technical support in the installation of network termination devices; and

 monitor all inbound and outbound interfaces and provide Agency with notice of inactive interfaces or
other potential connectivity issues.
The Contractor shall report monthly on Hosting Services activities, including the tracking and reporting of any
issues.

Documentation of hosting  Deliverable contains all
Monthly Hosting Services activities that includes reporting criteria agreed-upon in the
11.2
Report of service level adherence and DED.
incidents for the MVP.  Agency receives each report
on a monthly basis.
Task 11.3 – Security Reports

The Contractor shall provide security management. The Contractor shall, at a minimum and in accordance with
the Requirements and Exhibit B of the Agreement:
 ensure data center physical security measures and controls;

 ensure physical and logical security of all service components (hardware and software) and data;
 monitor the System for security errors, exceptions, and attempted violations;
 implement and monitor network intrusion and virus detection systems throughout hosted services
network and computing infrastructure;
 provide and maintain virus protection;
 report security violations to Agency; and
 provide and maintain all documentation required for security audits and internal control and control
testing.

The monthly reports must outline summary  Deliverable contains all
Monthly Security of any security incidents, breaches, criteria agreed-upon in the
11.3.1
Report intrusions, and issues AND their mitigation DED.
responses.  Agency receives each report
on a monthly basis.
Page 58 of 148
The alert notifications must be submitted  Agency receives each

Incident Report
11.3.2 to Agency within 2 hours of the time that notification within the
Alert
the breach, incident, or issue is identified. defined period.
Task 11.4 – Monthly Backup and Restore Reports

Contractor shall use the Hosting Services backup and restore methodology as described in the Accepted Hosting
Services Delivery Plan (Deliverable 11.1). Backups must occur and include, at a minimum:
 Regular backups of all System data;

 Backups of licensed software and third-party products; and
 Backup validation (restore).

The report must certify successful  Deliverable contains all criteria
Monthly Backup
11.4 backup validation of the System agreed-upon in the DED.
and Restore Report
and Agency Data.  Agency receives each report on a
monthly basis.
Task 11.5 – Business Continuity and Disaster Recovery (Hosting Services)

Contractor shall provide prioritized business continuity and disaster recovery services for the Hosting Services
and associated infrastructure (e.g., servers, network connection). The Contractor shall:
 Develop and maintain detailed business continuity and disaster recovery plans;
 Review and update the business continuity and disaster recovery plans on at least an annual basis;
 Develop action plan to mitigate risks and issues discovered during the business continuity and disaster
recovery plan review;
 Provide the Agency with copies of all updates to the business continuity and disaster recovery plans; and
 Perform an annual full System and database check.
Contractor shall initiate the disaster recovery plan in the event of a disaster recovery situation and notify the
Agency per the agreement and disaster recovery policies and procedures.
Page 59 of 148
 Updates are traceable to the

Updates to the DR/BC Plan based
Hosting Services setup.
on how the Hosting Services
 Documented completion of a
11.5.1 DR/BC Plan Update impacts disaster recovery
successful failover test or event.
procedures and business
 Oregon Votes Project Team
continuity processes.
approval.
 Documentation of Contractor’s
performance of the annual full
Annual updates based on any
System and database check.
Annual DR/BC Plan changes to Hosting Services and
11.5.2  Documented completion of a
Updates results of the annual full System
successful failover test or event.
and database checks.
approval.
Task 12.0 – Project Closeout

Period of Performance: September 2023 thru October 2023.
Purpose and Objective: The purpose of this Task is to review the implementation and formally close out the
Project.
Contractor shall perform all activities necessary to close out the project. This includes updating and transferring
all System Documentation to Agency.
Task 12.1 – Project Closeout Check List

Contractor shall provide a project closeout check list that shall, at a minimum, include a list of Deliverables,
Documentation, list of any outstanding issues with a related plan for remediation, and Final Acceptance. The
project closeout check list shall be in the form and format agreed to by the Agency.

Checklist document that confirms all  Deliverable contains all criteria
implementation tasks have been agreed-upon in the DED.
Project completed, all implementation Deliverables  Oregon Votes Project Team
12.1 Closeout have been accepted, and confirms the confirms all implementation tasks
Checklist completion of activities that are needed to and Deliverables have been
officially close the Implementation Phase of completed and accepted.
the Project.  Oregon Votes Steering Committee
approves Project closeout.
Page 60 of 148
Task 12.2 – Transfer of Materials

At the completion of Phase 2 System Stabilization Period of the Project, the Contractor shall conduct a review
with the Agency and identify any documentation that shall be updated because of changes during the Post-
Implementation Warranty Period or M&S Period(s). The Contractor shall update the documentation and provide
them to Agency for review and final acceptance.
The Contractor shall identify any Agency or County proprietary documentation and return it to Agency and the
County (or Counties). Any electronic copies of proprietary information stored on Contractor equipment shall be
deleted or transferred back to Agency and the County (or Counties).
 All documentation
At the completion of the Post-
identified by Agency is
Implementation Warranty Period, the
updated.
Contractor shall conduct a review with the
Updated System Agency and identify any documentation
approves of all updates
12.2 Documentation that must be updated as a result of changes
made to identified
(Project Closeout) during the Post-Implementation Warranty
documentation.
Period. The Contractor shall update the
 Oregon Votes Steering
documentation and provide them to the
Committee approves
Agency for review and Acceptance.
Project closeout.
D. Payment Schedules
1. Contractor Hourly Rate Card
The following hourly rates will be used to estimate costs and inform pricing on future Enhancements and
additional Services.
Classification Hourly Rate

Project Executive $175.00
Project Manager $150.00
Business Analyst $110.00
Technical Analyst $110.00
Page 61 of 148
Data Analyst $110.00
Developer $115.00
Tester $80.00
DBA $125.00
Architect $150.00
2. Project Planning and Implementation Service Fees

Agency will pay Contractor for Implementation Services based on the payment schedule below. Contractor may
request payment of the “Full Amounts for Milestone” with respect to each Milestone when Contractor has
delivered and Agency has Accepted each of the Deliverables To be Completed for each Milestone as set forth
below.
Milestone Deliverables To be Itemized Full Amounts Cumulative

No. Date
Name Completed Amt for Milestone Total
Ongoing Project
Management and
Project Status Reporting,
1 31-Aug-21 $64,000.00 $120,000.00 $120,000.00
Management Scope Reviews
(Deliverables 1.2.1,
1.2.2, & 1.3)
Project Kick-Off
(Deliverable 1.1.1 $20,000.00
& 1.1.2)
Project
Management Plan
$36,000.00
and Schedule
(Deliverable 1.0)
Ongoing Project
Management and
Requirements, Status Reporting,
2 31-Oct-21 $32,000.00 $334,500.00 $454,500.00
Data Mapping Scope Reviews
1.2.2, & 1.3)
RTM (Functional,
$85,000.00
Technical and
Page 62 of 148

No. Date
Interface
Requirements)
(Deliverable 3.1)
Data Migration
Mapping $75,000.00
(Deliverable 6.1)
System
Development and
Configuration: Part
1 –Completed
$142,500.00
Sprint 2
(Verifiable
progress on Task
5.1)
Ongoing Project
Management and
Functional Status Reporting,
3 20-Dec-21 $32,000.00 $334,500.00 $789,000.00
Design Scope Reviews
1.2.2, & 1.3)
Functional Design
$60,000.00
(Deliverable 4.1)
System
Development and
Configuration: Part
2. Completed
$142,500.00
Sprint 5
(Verifiable
progress on Task
5.1)
Periodic
Development
Review: Part 1:
$100,000.00
(Verifiable
progress on Task
5.2)
Page 63 of 148

No. Date
Ongoing Project
Management and
Technical
Status Reporting,
4 Design, 28-Feb-22 $32,000.00 $313,500.00 $1,102,500.00
Scope Reviews
OCM
1.2.2, & 1.3)
Technical Design
$91,000.00
(Deliverable 4.2)
Security Plan
$15,000.00
(Deliverable 4.3)
OCM
$33,000.00
2.1.2, 2.2.1, 2.2.2,
2.3m and 2.4.1)
System
Development and
Configuration: Part
3. Completed
$142,500.00
Sprint 7
(Verifiable
progress on Task
5.1)
Ongoing Project
Management and
Hosting,
Status Reporting,
5 Development – 30-Apr-22 $32,000.00 $339,500.00 $1,442,000.00
Scope Reviews
Sprint 10
1.2.2, & 1.3)
Hosting Services
Delivery Plan $24,000.00
(Deliverable 11.1)
Disaster Recovery
Plan $15,000.00
(Deliverable 4.4)
Periodic
Development $100,000.00
Review: Part 2:
Page 64 of 148

No. Date
(Verifiable
progress on Task
5.2)
System
Development and
Configuration: Part
4. Completed
$142,500.00
Sprint 10
(Verifiable
progress on Task
5.1)
OCM Periodic
Reports $6,000.00
(Deliverable 2.4.2)
Training Plan
$20,000.00
(Deliverable 9.1.1)
Ongoing Project
Management and
Development – Status Reporting,
6 30-Jun-22 $32,000.00 $320,500.00 $1,762,500.00
Sprint 13 Scope Reviews
1.2.2, & 1.3)
User
Documentation $40,000.00
(Deliverable 9.3)
Periodic
Development
Review: Part 3:
$100,000.00
(Verifiable
progress on Task
5.2)
OCM Periodic
Reports $6,000.00
(Deliverable 2.4.2)
System
Development and $142,500.00
Configuration: Part
Page 65 of 148

No. Date
5. Completed
Sprint 13
(Verifiable
progress on Task
5.1)
Ongoing Project
Management and
Development Status Reporting,
7 31-Aug-22 $32,000.00 $355,500.00 $2,118,000.00
Completion Scope Reviews
1.2.2, & 1.3)
Interface
Development $120,000.00
(Deliverable 9.3)
System
Documentation
$15,000.00
Updates
(Deliverable 5.3.1)
System
Development and
Configuration: Part
6. (Verifiable
$142,500.00
progress on Task
5.1 and
Acceptance of
Deliverable 5.1.1)
OCM Periodic
Reports $6,000.00
(Deliverable 2.4.2)
User Training
(Deliverables 9.1.2 $40,000.00
& 9.2)
Ongoing Project
Management and
8 System Test 31-Oct-22 $32,000.00 $185,000.00 $2,303,000.00
Status Reporting,
Scope Reviews
Page 66 of 148

No. Date
1.2.2, & 1.3)
System Testing
$122,000.00
(Deliverable 7.1.1)
Implementation
Services Plan
$25,000.00
(Deliverable
10.1.1)
OCM Periodic
Reports $6,000.00
(Deliverable 2.4.2)
Ongoing Project
Management and
Status Reporting,
9 Data Migration 31-Dec-22 $32,000.00 $138,000.00 $2,441,000.00
Scope Reviews
1.2.2, & 1.3)
Data Migration
Report $75,000.00
(Deliverable 6.2.1)
User Migration
Report $10,000.00
(Deliverable 6.3.1)
Load Test
$15,000.00
(Deliverable 7.1.2)
OCM Periodic
Reports $6,000.00
(Deliverable 2.4.2)
Ongoing Project
Management and
UAT and Mock Status Reporting,
10 28-Feb-23 $32,000.00 $232,000.00 $2,673,000.00
Election Scope Reviews
1.2.2, & 1.3)
Page 67 of 148

No. Date
UAT
$75,000.00
(Deliverable 7.2.1)
Mock Election
$40,000.00
(Deliverable 7.3)
Helpdesk Plan
$40,000.00
Deliverable 10.1
System
Documentation
Updates and
System Operations $39,000.00
Documentation
(Deliverables 7.5.1
& 7.6.1)
OCM Periodic
Reports $6,000.00
(Deliverable 2.4.2)
Ongoing Project
Management and
Status Reporting,
11 MVP Closeout 30-Apr-23 $32,000.00 $529,857.14 $3,202,857.14
Scope Reviews
1.2.2, & 1.3)
System
Development and
Configuration: Part $285,000.00
7. (Deliverable
5.1.1)
MVP Data
Conversion and
Synchronization $125,000.00
Completion
(Deliverable 6.2.1)
System
Documentation
$15,000.00
Updates
(Deliverable 5.3.1)
Page 68 of 148

No. Date
Monthly Hosting
Services Reports
$12,857.14
(Deliverables 11.2,
11.3, and 11.4)
MVP Warranty
& 8.5.2)
Phase II
Requirements
$30,000.00
Validation
(Deliverable 3.2)
Ongoing Project
Management and
Phase II Status Reporting,
12 30-Jun-23 $32,000.00 $184,857.14 $3,387,714.28
Development Scope Reviews
1.2.2, & 1.3)
Phase II
Development and
Configuration: Part
$100,000.00
1. (Verifiable
progress on Task
5.1)
DR and BCD
Update
$10,000.00
(Deliverable
11.5.1)
Monthly Hosting
Services Reports
$12,857.14
(Deliverables 11.2,
11.3, & 11.4)
MVP Warranty
& 8.5.2)
Phase II Go- Ongoing Project

13 30-Aug-23 $32,000.00 $174,857.14 $3,562,571.42
Live Readiness Management and
Page 69 of 148

No. Date
Status Reporting,
Scope Reviews
1.2.2, & 1.3)
Phase II
Development and
Configuration: Part
$100,000.00
2. (Verifiable
progress on Task
5.1)
Monthly Hosting
Services Reports
$12,857.14
(Deliverables 11.2,
11.3, & 11.4)
MVP Warranty
& 8.5.2)
Ongoing Project
Management and
System Status Reporting,
14 31-Oct-23 $32,000.00 $697,428.58 $4,260,000.00
Implemented Scope Reviews
1.2.2, & 1.3)
Phase II
Development
Completion – Part $100,000.00
3. (Deliverable
5.1.2)
System
Deployment $400,000.00
(Deliverable 8.3.7)
MVP Warranty
& 8.5.2)
Monthly Hosting
$6,428.58
Services Reports
Page 70 of 148

No. Date
(Deliverables 11.2,
11.3, & 11.4)
Project Closeout
$99,000.00
(Deliverable 12.1)
System
Documentation
Updates and
$30,000.00
Transfer of
Materials
(Deliverable 12.2)
TOTAL OF IMPLEMENTATION PAYMENTS: $ 4,260,000
3. Ongoing Maintenance and Support Fees

Agency will pay Contractor the fee amounts listed below. During the M&S Period of Performance, Contractor
shall invoice Agency at the time of the payment milestones during implementation, as specified in Part D.2
above. After Agency Acceptance of Project Closeout, including payment of the final Implementation Milestone,
Contractor shall invoice Agency Quarterly.
Support Year
Support M&S Period of Monthly Service
(Starts after Description Not-to-Exceed
Months Performance Charge*
MVP go-live)
Jun 2021 –
0 No M&S Services N/A N/A
Feb 2023
Mar 2023 – Start after Implementation

1 6 $390,000.00 $65,000.00
Aug 2023 of MVP
Sep 2023 – Start after Implementation

2 12 $795,000.00 $66,250.00
Aug 2024 of Phase 2
Sep 2024 –
3 12 Continuation $834,750.00 $69,562.50
Aug 2025
Sep 2025 –
4 10 Continuation $731,250.00 $73,125.00
Jun 2026
Total Maintenance and Support Fees for this Transaction Document: $2,751,000.00
*See Part B of Schedule 2 for implications and definition.
Page 71 of 148
4. Software Licensing and Hosting Service Fees

The table below defines the coverage periods for software licensing and the provision of Hosting Services.
Year Coverage Period
1 June 2021 - June 2021
2 July 2021 - June 2022
3 July 2022 - June 2023
4 July 2023 - June 2024

5 July 2024 - June 2025
6 July 2025 - June 2026
Agency will pay Contractor the fee amounts listed below for coverage periods defined above. Except for the Year
1 Software Licensing Fee, which will be invoiced by June 30, 2021, Contractor shall invoice Agency at the time of
the payment milestones during implementation, as specified in Part D.2 above.
After Agency Acceptance of Project Closeout, including payment of the final Implementation Milestone,
Contractor shall invoice Agency for Hosting Services Quarterly in advance.
Software Licensing Fees will be paid annually in advance of the year covered.
Description Year 1 Cost Year 2 Cost Year 3 Cost Year 4 Cost Year 5 Cost Year 6 Cost
Software Licensing
Fee for all of the
products listed in $750,000.00 $0.00 $0.00 $60,000.00 $175,000.00 $175,000.00
Schedule 7, Section
A.
Total for Software Licensing Fees: $1,160,000.00
Hosting for Testing

$0.00 $84,000.00 $84,000.00 $84,000.00 $84,000.00 $84,000.00
Environment
Hosting for UAT /

Mock Election $0.00 $0.00 $60,000.00 N/A N/A N/A
Environment
Hosting for
Production N/A N/A $90,000.00 $216,000.00 $228,000.00 $240,000.00
Environment (2 sites)
Page 72 of 148
Total for Hosting Services Fees: $1,254,000.00
5. Contingency Amount for System Enhancements

a. Enhancements. Either Agency or Contractor may recommend Enhancements to the System. Contractor
and Agency shall consider and enter into Change Orders to complete Enhancements in accordance with
Section 10 of the Agreement, or Contractor and Agency may agree to enter into a separate Transaction
Document that describes each Party’s obligations with respect to the completion and payment for the
Enhancement. Sections b and c below do not govern payment, invoicing or any limits on payments with
respect to Enhancements that the Parties agree to complete under a separate Transaction Document,
and the terms of such Transaction Document will govern the parties obligations with respect to
Enhancements described in it.
b. Payment for Enhancements. Agency may agree to pay Contractor to complete Enhancements on either
an hourly basis, or on the basis of fixed prices paid for Deliverables submitted by Contractor and
Accepted by Agency, as set forth in the Change Order. Contractor may provide a credit to Agency for any
charges invoiced in a particular month for work on Enhancements based on the availability of Contractor
staff otherwise responsible for fulfilling Contractor’s obligations for Maintenance and Support under
Task 10 above. In addition, upon agreement of the Parties, Contractor may complete minor changes and
Enhancements without additional charge to Agency. Contractor’s charges for completing an
Enhancement may exceed the amount set forth in the Change Order provided that both (i) the amount
of such excess is less than 20% of the amount set forth in the Change Order for completion of the
Enhancement, and (ii) the charges comply with the limits set forth in Section D.5.c below.
c. Invoicing and Limits on Payments. Contractor may submit invoices for Services to complete
Enhancements no less frequently than monthly. Agency will pay such invoices in accordance with the
terms of the Agreement. Any payments made for Enhancements will be deducted from the Contingency
Amount set forth below. Agency’s payments to Contractor under this Section D.5 for Enhancements
completed during the term of this Transaction Document may not exceed the Contingency Amount set
forth below, which the Parties may amend by written Agreement.
Contingency Amount -- $420,000.00
E. SOW Definitions
Acronym/Term Definition
A/V Equipment means devices used to capture and record both audio and
A/V Equipment
visual stimuli in real-time.
ACP refers to a member of the Oregon Department of Justice's Address
ACP
Confidentiality Program.
Page 73 of 148
"Agency" means the State of Oregon, acting by and through its Secretary of
Agency
State's Office.
Agency PM means Agency Project Manager, as that individual is identified in
Agency PM
Schedule 5.
In software development, the Agile Method promotes iterative development
Agile Method throughout the life cycle of the project, close collaboration between the
development team and business side, and constant communication.
ArcGIS is a software program that allows an end-user to make digital maps with
ArcGIS authoritative location data that can then be shared and exported for use in the
System.
In the Agile Method, the primary purpose of a backlog grooming session is to
Backlog Grooming ensure the next few sprints worth of user stories in the product backlog are
prepared for sprint planning.
CISO CISO means Agency’s "Chief Information Security Officer".
Client Environments means Agency- and County-owned equipment, such as
Client Environments personal computers, peripheral monitors, printers, ballot sorters, and
tabulators.
DAR (Deliverable DAR means a "Deliverable Acceptance Request", which is a Project artifact that
Acceptance Request) memorializes Agency’s Acceptance of one or more Deliverable(s).
DBA means Database Analyst, which refers to a worker's classification and
DBA requires certain skillsets and experience in order to perform certain portions of
this SOW successfully.
DED DED means a Deliverable Expectation Document.
Disaster Recovery/Business Continuity Plan means the accepted plan provided
Disaster under Task 11.5, in the context of this Project, a set of policies and processes
Recovery/Business for the Solution that are intended to protect the System from any significant
Continuity Plan effects in the case of a negative event (such as cyberattacks, device failure(s),
natural disasters, and so on).
DR/BC Plan DR/BC Plan means "Disaster Recovery/Business Continuity Plan".
Election Laws refers to the relevant and applicable federal, state and local laws,
Election Laws
rules, and standards for how Oregon administers its elections.
System functionality that assists Agency and Counties in managing temporary
Election Worker workers and volunteer staff that are needed to process mail-in ballots on and
before Election Day.
ENR (Election Night ENR means Election Night Reporting, which is the systematic process of quickly
Reporting) reporting election results to the general public.
ERIC ERIC means the Electronic Registration Information Center.
ESRI Grid ESRI Grid is a type of GIS file format.
A File Geodatabase, or GDB for shorthand, means a collection of files that can
File Geodatabase (GDB)
store, query, and manage spatial and nonspatial data.
FPCA FPCA means a Federal Post Card Application.
Page 74 of 148
Functional Functional Requirements refer to the subset of Requirements specified in Part B

Requirements of Schedule 9.
GeoPackage GeoPackage refers to an open format for geospatial information.
GIS GIS means geographic information system.
The Golden Button is a System function whereby Users can click a button that
will automatically set up a support ticket and automatically provides requisite
Golden Button
details into required fields, such as a User’s Browser and current version,
location within the System application, and so on.
HAVA HAVA means the Help America Vote Act.
Hosting Services means a service through which storage and computing
resources are provided to an individual or organization for the accommodation
Hosting Services and maintenance of applications, infrastructure, and other information
technology needs. As of the Transaction Document Effective Date, Microsoft
Azure is the collection of Hosting Services for the System.
JAD JAD stands for "joint application development" sessions.
Keyhole Markup KML means a markup language based on XML and useful for describing and
Language (KML) implementing 2D and 3D visual shapes on HTML-based browsers.
KPI KPI means Key Performance Indicator, as that term is used in Schedule 2.
Layers (LYR) means a file that stores the path to a source dataset and other
Layers (LYR)
layer properties.
MFA MFA means "Multi-Factor Authentication".
MVP stands for "Minimum Viable Product". In the context of this Project, the
MVP Minimum Viable Product means an incomplete System that meets some, but
not all of the Requirements
Non-Functional Non-Functional Requirements refer to the subset of Requirements specified in
Requirements Part C of Schedule 9.
OCM means Organizational Change Management, and means a framework
structured around the changing needs and capabilities of an organization that is
used to prepare, adopt, and implement organizational changes. For purposes of
OCM
this RFP, organizational changes may include changes in culture, policies,
processes/procedures, and environment(s), as well as employee roles,
responsibilities, and required skillsets.
OCVR means the Oregon Centralized Voter Registration system, which is the
OCVR
primary legacy system to be replaced by the System.
OCVR Database Analyst, or OCVR DBA, means the Agency's authorized agent to
OCVR Database Analyst
perform DBA-specific work as specified in Task 6.
OpenStreetMap refers to the online service, further specified online at
OpenStreetMap (OSM)
https://openstreetmap.org.
Oregon Votes is the Agency's branding for the Project and System on the
Oregon Votes
Transaction Document Effective Date.
Page 75 of 148
Oregon Votes Project The Oregon Votes Project Team comprises the Agency personnel in Schedule 5,
Team except for the Procurement Specialist.
Oregon Votes Steering The Oregon Votes Steering Committee is the Agency’s executive steering
Committee committee for the Project, tasked with providing project stage gate approvals.
The Oregon Votes County Subcommittee is a representative sample of some
Oregon Votes County
Oregon Counties, serving in an advisory role to the Oregon Votes Project Team
Subcommittee
and providing leadership to other Counties for adoption of the System.
Period of Performance means the duration of time that certain Tasks are to be
Period of Performance
performed.
Phase 1 of the Project means the first part of the implementation phase work
Phase 1
and is used interchangeably with "MVP".
Phase 2 of the Project means the second part of the implementation work,
Phase 2
where the deployed System meets all of the Requirements.
PII PII means "Personally Identifiable Information".
Product Owner means the Agency individual responsible for maximizing the
Product Owner
System's value for the State. The Product Owner is identified in Schedule 5.
The Production Environment, also referred to as "Production" for shorthand,
Production
means the environment that the System is put into operation for its intended
(Environment)
use and made available to the intended Users.
"Project" means the Oregon Votes Project, including its three phases: MVP
Project (Phase 1) deployment, Phase 2 deployment, and implementation closeout
activities (Task 12).
A Public User means an Oregon resident who is a voter or potential voter, who
Public User(s)
will have access and may interact with the System's online portal.
Requirements refer to the System Functional and Non-functional Requirements
Requirement(s)
specified in Schedule 9.
A Shapefile (SHP) means a digital vector storage format for storing geometric
Shapefile (SHP)
location and associated attribute information.
SME SME means Subject Matter Expert.
SMS SMS means Short Message Service.
SOW SOW means this Statement of Work.
A Sprint means a Project activity that involves development and early User
Sprint(s)
testing to further inform the development and configuration of the System.
SSN SSN means Social Security Number.
State State means the State of Oregon.
System means the sum total of the Services, the Deliverables, the Contractor
Intellectual Property, the Third-Party Intellectual Property the Software, the
System
hardware (if applicable), Hosting Services, and the Documentation described in
one or more Transaction Documents that comprise the information system that
Page 76 of 148
Contractor will deliver, develop, install, configure, implement, enhance, and

maintain under this Agreement and such Transaction Documents.
System Documentation means all documents, including documents that are
Deliverables which may include any and all operator’s and user’s manuals,
training materials, guides, commentary, listings, requirements traceability
System Documentation
matrices and other materials for use in conjunction with and for the operation
of the System and its components that are to be delivered by Contractor.
System Documentation includes documents in hard copy or electronic form.
Task Task means a segment of the Services to be performed in the SOW.
TotalAddress TotalAddress means one of the software applications comprised by the System.
TotalVote TotalVote means one of the software applications comprised by the System.
UOCAVA means an eligible voter under the Uniformed and Overseas Citizens
UOCAVA Absentee Voting Act (and as amended under the Military and Overseas Voter
Empowerment Act).
User(s) User means an Agency and/or County end-user of the System.
USPS USPS refers to the United States Postal Service.
Voluntary Voting System Guidelines (VVSG) are a set of specifications and
Voluntary Voting requirements against which voting systems can be tested to determine if the
System Guidelines systems meet required standards. Some factors examined under these tests
(VVSG) include basic functionality, accessibility, and security capabilities. HAVA
mandates that EAC develop and maintain these requirements.
Web Services refer to software applications with standardized ways of
Web Services
providing interoperability between disparate applications.
Page 77 of 148
SCHEDULE 2 – SERVICE LEVELS AND CREDITS
A. Overview
The Fee Reductions (as defined below) have been designed to encourage the consistent and timely delivery of
service and value to Agency. Fee Reductions are not intended to compensate Agency for damages, but rather to
reimburse Agency for the value of the diminished services actually delivered, and to provide incentive to
Contractor to achieve the stated objectives and focus on Agency’s critical needs.
This Schedule outlines the circumstances under which Contractor will be subject to Fee Reductions for failure to
achieve the Service Level Requirements (SLRs).
For the purposes of this Schedule, “Failure,” shall mean, with respect to any SLR or KPI, the failure to meet the
specified Performance Requirement for the SLR/KPI for the applicable Measurement Period. This Schedule
describes the methodologies associated with measurement of and reporting on the results achieved regarding
the Service Level Requirements defined below. It sets out the parameters for measuring Service Levels, including
eligibility for low volume sample sizes in a Measurement Period, and remedies for SLR Failures. Regardless of
SLR or KPI designation (i.e. critical or non-critical), Contractor shall perform a Root Cause Analysis (RCA) for any
failure to attain the Performance Requirement. This RCA shall be provided to Agency within five (5) business
days of the reported failure and include actions (with completion dates) to prevent recurrence of the failure.
B. Definitions and Effects
Term Definition
Application Release means an updated version of the System software that

Application Releases
will be deployed into Agency’s Production environment.
The At-Risk Amount is the maximum amount of a Credit Rebate that Agency
is entitled to with respect to any SLR during the SLR’s Reporting Period, and
At-Risk Amount is equal to 10% of the sum total amount payable for Ongoing Maintenance
and Support Fees (Schedule 1, Part D.3) during the applicable Reporting
Period.
Page 78 of 148
On the anniversary of the date that Agency notifies Contractor of successful

completion of the Phase 2 System Stabilization Period (and annually
thereafter), those SLRs or KPIs marked “Continual Improvement Eligible”
shall have their Performance Requirement improved by 5% of the gap
between current Performance Requirement and perfection.
Example: An SLR with a Performance Requirement of 80% would improve

according to:
Continual Improvement
Perfection = 100%; Difference between current target and perfection =
100% minus 80% = 20%. An improvement of 5% on the 20-% gap equals 5%
times 20% = 1%
The new Performance Requirement would be 81%
For clarity, those SLRs where a lower percentage is the desired outcome,
perfection is assumed to be 0%.
Credit Rebate means an SLR that is eligible to earn back a Fee Reduction by
continuously meeting or exceeding the SLR for consecutive Measurement
Periods. If Contractor believes it is entitled to a Credit Rebate it shall notify
Credit Rebate Agency and provide documentation demonstrating that it has earned the
Credit Rebate. Contractor may invoice Agency for a Credit Rebate in the
first monthly invoice following Agency’s confirmation that Contractor is
entitled to the Credit Rebate.
A CSP Passthrough is a type of SLR Credit where the Parties have agreed
that Failure is mostly or entirely the result of the cloud hosting provider.
The amount of a CSP Passthrough is determined by the CSP. In this event,
any credits given to the Contractor by the CSP during the Measurement
CSP Passthrough Period shall be given to Agency as a credit. CSP Passthrough SLR Credits are
not subject to earn back. Any CSP Passthrough SLR Credits will not be
counted against the At-Risk Amount for purposes of calculating the
maximum SLR Credits to which Contractor may be subject during any
period.
Elections Business Hours means 8am – 5pm PT, except for Election Days.
Election Business Hours
On an Election Day, Election Business Hours are 7am – 10:00pm PT.
Election Cycle means the period of time starting on the day after the date
Election Cycle
of a general election and ending on the date of the next general election.
The complete 24-hour day on which an election is conducted within the

Election Day
State of Oregon.
A Fee Reduction means the reduction in the amount payable for an invoice
that is equal to the total SLR Credit for a given Measurement Period
Fee Reduction multiplied by the At-Risk Amount. The sum of all Fee Reductions during a
Measurement Period shall not exceed the total At-Risk Amount for that
Measurement Period.
Key performance measures that must be monitored, measured, and
Key Performance Indicators (KPIs)
reported to Agency. Failure to meet KPIs do not result in Fee Reductions.
Page 79 of 148
Low Volume means a SLR for which a single failure of an event-based

measurement results in the failure to meet the SLR. If an SLR designated as
Low Volume
Low Volume in this Schedule 2, then the first failure to meet the SLR during
any Measurement Period will not result in the imposition of a SLR Credit.
The M&S Period of Performance starts on the day following completion of

M&S Period of Performance the System Implementation Warranty Period, when the Agency is directly
paying for System Maintenance and Support, as detailed in Task 10.2.
Measurement Period means the time during which an SLR or KPI is to be
measured and assessed against the Performance Requirement. The start of
Measurement Period
the Measurement Period will begin after completion of the System
Implementation Warranty Period.
if the Measurement Period is designated as “Annual,” it shall mean the
period commencing 12:00 a.m. on the first day following the end of the
System Implementation Warranty Period and ending 12:00 a.m. on the first
day of the period beginning one year after that date.
Measurement Period – Annual
For clarity, “Annum” or “Annual Period” means a one-year period during
the M&S Period of Performance that begins on a yearly anniversary of the
beginning of the M&S Period of Performance.
If the Measurement Period is designated as “monthly,” it shall mean the
period commencing 12:00 a.m. on the first day of each month and ending
Measurement Period – Monthly 12:00 a.m. on the first day of the following month.
For clarity, “Month” means a calendar month.
If the Measurement Period is designated as “Quarterly,” it shall mean the
period commencing 12:00 a.m. on the first day of each Quarter and ending
12:00 a.m. on the first day of the Quarter.
Measurement Period – Quarterly
For clarity, “Quarter” means each consecutive three-month period during
the M&S Period of Performance, the first of which begins on the first day of
the M&S Performance Period.
If the Measurement Period is designated as “Semi-Annual,” it shall mean
one of the two periods in an Annum, the first of which commences at 12:00
a.m. on the first calendar day of the Annum, and the second commencing
Measurement Period – Semi-Annual at 12:00 a.m. on the first day of the seventh month of an Annum.
For clarity, a “Semi-Annum” is either the first or last six consecutive month
period during an Annum.
Monthly Service Charge means, for any given calendar month of the M&S
Period of Performance, the actual or pro-rated dollar amount of all fees
Monthly Service Charge
billed to Agency for Services provided in such month pursuant to Schedule
1, Part D.3.
Planned Downtime means pre-scheduled period or periods of time,

Planned Downtime
approved by Agency, during which the System is unavailable to Users.
Services and operational levels where the performance requirement
indicates a critical business requirement. SLRs are monitored, measured,
Service Level Requirements (SLRs)
and reported to Agency. Failure to meet an SLR results in a Fee Reduction
unless it is Low Volume eligible (see definition below).
Page 80 of 148
Service Level Response Times refers to Contractor’s obligation of

responding to Agency’s support request tickets, within the timeframes
defined in this section. Service Level Response Times are categorized as
“Criticality 1”, “Criticality 2”, and “Criticality 3”, each defined below.
“Criticality 1” means the production environment is seriously impacted by

some issue or is out of service. There is no work-around available for this
criticality status. Initial response and beginning of resolution occur within 1
hour of Agency submitting its request. Status updates are provided to
Agency every hour after the initial response.
Service Level Response Times “Criticality 2” means production is operable, but a serious issue has
occurred. Production is functioning at a sub-standard level. Initial response
is given within 4 hours, and beginning of resolution occurs within 8 hours,
of Agency submitting its request. Status updates are provided to Agency
once a day.
“Criticality 3” means a minor problem or small enhancement request.
These issues will be resolved according to the routine build schedule. Initial
response is given within 8 hours. Beginning of resolution occurs as
prioritized by mutual collaboration between Agency and Contractor. Status
updates are provided to Agency once a week.
Unplanned Downtime/Outage means an event and period of time where

Unplanned Downtime/Outage
the System is unavailable and is not Planned Downtime.
C. Contractor Support Services
SLR 1 – Updated User Documentation
Service Level Explanation
Contractor shall provide updates to the user documentation during the M&S Period of
Description Performance of this Transaction Document reflecting applicable changes based on new
releases, System enhancements, and System updates.
Following the close of a Measurement Period, Agency will review User Documentation
version histories to ensure Documentation has either been updated, or acknowledged
Formula no updates were needed per the Contractor. Agency will complete this review and note
deficiencies to Contractor by the end of the Reporting Period following the end of the
previous Measurement Period.
Performance
100% User Documentation updates by the end of the Measurement Period.
Requirement
Measurement
Annually
Period
Page 81 of 148
Reporting Period Quarterly
Measurement
User Documentation files located and accessible to Users in the System.
Tool/Source Data
Low Volume
No
Eligible
Continual
Improvement No
Eligible
Designation SLR
Yes: Any User Documentation found by Agency to have not been updated, Contractor
Credit Rebate
shall make the required updates by the end of the following Reporting Period.
SLR Credit
25
Percentage
KPI 1 – Support Request Response Time Compliance
Description Percentage of support request tickets adhering to the Service Level Response Times.
Number of tickets submitted that do comply with the Service Level Response Times,
Formula
divided by the number of tickets submitted during the Measurement Period.
Criticality 1 – 95%
Performance
Requirement
Measurement
Monthly
Period
Reporting Period Monthly
Page 82 of 148
Contractor will provide periodic status reports of reported issues as recorded in Team
Measurement Foundation Server (TFS). Contractor PM will work with the Agency PM to establish
Tool/Source Data methods for calculating response times in TFS or identify tickets where response time
requirements were not adequately met.
Continual Yes: After each Annual Period, the Performance Requirement (for each criticality level)
Improvement will increase by one percentage point, up to a maximum Performance Requirement of
Eligible 99%.
Designation KPI
SLR Credit
N/A
Percentage
KPI 2 – Security Notifications
Contractor shall ensure prompt notifications of security breaches or related incidents

Description
within the System (e.g., Application, or Hosting Services, or both).
The timeframe starts when Contractor becomes aware of a security breach or incident,
regardless of Contractor becoming aware via its personnel or via electronic notification
Formula delivered and accessible on Contractor’s equipment. In any event, once Contractor has
been made aware of the breach is when the “clock starts” on the Performance
Requirement.
Performance
Notification must be delivered to Agency within two hours.
Requirement
Measurement
Monthly
Period
Contractor will establish system alert emails and notifications from the Test and
Production environments for identified incidents, that will be sent to the approved
Measurement personnel on both teams.
Tool/Source Data
Procedures will be established to deal with any potential security breach identified by
the security architecture of the system or reported by system users.
Designation KPI
Page 83 of 148
SLR Credit
N/A
Percentage
KPI 3 – Tickets Reopened
Description The percentage of tickets reopened within the same Measurement Period.
Number of tickets reopened during the Measurement Period, divided by the number of
Formula
tickets submitted during the same Measurement Period.
Performance
<5%
Requirement
Measurement
Quarterly
Period
Measurement
Contractor will provide statistics of tickets reopened within the specified period.
Tool/Source Data
Continual Yes: After each Annual Period, the Performance Requirement will be adjusted
Improvement downward by a percentage point until it reaches a Performance Requirement of less
Eligible than or equal to 1%.
Designation KPI
SLR Credit
N/A
Percentage
KPI 4 – New Application Release Notifications
Page 84 of 148
Advanced notification delivered to Agency for new/upcoming Application Releases that

Description
will be deployed into Agency’s environment.
Number of calendar days between Agency’s receipt of Contractor notification and the
Formula
date scheduled for the Application Release deployment.
General
Performance At least 60 days before scheduled deployment of the Application Release.
Requirement
Measurement
Quarterly
Period
Contractor PM/Service Manager will provide a 3-6 month release schedule as part of
Measurement
status reporting. Release schedules will be presented in periodic project review
Tool/Source Data
meetings and approved by the Agency.
Continual
Improvement No
Eligible
Designation KPI
SLR Credit
N/A
Percentage
D. System Performance
SLR 2 – Recovery Point Objective
The maximum amount of data – as measured by time – that can be lost after a recovery
Description
from a disaster, failure, or comparable event.
Formula See Description
Performance
<5 seconds per event
Requirement
Page 85 of 148
Measurement
Monthly
Period
Measurement Details of any data lost will be identified, analyzed, and reported using reported tickets,
Tool/Source Data Application Insights and database queries by the Contractor.
Low Volume
No
Eligible
Continual
Improvement No
Eligible
Yes: If this SLR reaches Failure, Contractor shall be entitled to recover the Fee
Credit Rebate Reduction by continuously complying with the Performance Requirement for 6
consecutive Measurement Periods.
Designation SLR
SLR Credit
If Contractor’s at fault = 75 | If Contractor’s NOT at fault = CSP Passthrough
Percentage
SLR 3 – Recovery Time Objective
The amount of time for the System to become available to the Users after Unplanned
Description
Downtime occurs during Election Business Hours.
The time the System is restored after the beginning of Unplanned Downtime, minus the
Formula
time the System went offline and became unavailable to the Users.
Performance
<30 seconds per Unplanned Downtime event
Requirement
Measurement
Monthly
Period
Page 86 of 148
Measurement
Contractor will provide statistics using Application Insights.
Tool/Source Data
Low Volume Yes: This SLR’s Low Volume Eligibility is limited to one Failure per Unplanned
Eligible Downtime event per each Annual Period.
Continual
Improvement No
Eligible
Yes: If this SLR reaches Failure, Contractor shall be entitled to recover the Fee
Credit Rebate Reduction by continuously complying with the Performance Requirement for 6
consecutive Measurement Periods.
Designation SLR
SLR Credit
Percentage
SLR 4 – Application Availability
Description Measure of uptime during the Measurement Period.
With a requested and proposed uptime of 99.99% for the System, the Parties agree that
Formula
Unplanned downtime calculates to 52 minutes and 35 seconds per calendar year.
Performance
No more than one cumulative hour of Unplanned Downtime.
Requirement
Measurement
Annual
Period
Page 87 of 148
Measurement Contractor will provide statistics of uptime from Application Insights the monitoring tool
Tool/Source Data that will be used for monitoring the System.
Low Volume
No
Eligible
Continual
Improvement No
Eligible
Credit Rebate No
Designation SLR
SLR Credit
Percentage
SLR 5 – Election Day Application Stability
Number of Unplanned Downtime events, on Election Day, within the reporting period,
Description
regardless of the duration of the outage.
Formula Number of Unplanned Downtime events that the System is unavailable to Users.
Election Day
Performance Zero
Requirement
Measurement
Monthly
Period
Page 88 of 148
System Outage incidents as reported will be recorded in the ticketing system (proposed
Microsoft DevOps {TFS} or its equivalent). These will be marked as critical tickets and
worked on and tracked in the ticketing system.
For each outage, system incident reports will be provided for Agency review. These
incident reports will include:
• Incident Description
• Incident Cause
Measurement • User and System Impact
Tool/Source Data
• Corrective Action/Proposed Resolution
• Current State
• Remedial Action for Future Mitigation/Prevention
As part of the support deliverables, Team TotalVote will report the outages on a
quarterly basis summarizing the incidents that occurred during that period.
Additional details and outage statistics will be provided from the Application logs from
Application Insights.
Low Volume
No
Eligible
Continual
Improvement No
Eligible
Credit Rebate No
Designation SLR
SLR Credit
100
Percentage
KPI 5 – System Performance Degradation
Number of tickets submitted during the Measurement Period noting system degradation
Description
issues and/or "slowness".
Formula See Description
Page 89 of 148
Performance
Report number of Track tickets that note degradation or System slowness.
Requirement
Measurement
Monthly
Period
Contractor will provide periodic status reports indicating the ticket counts along with the
ticket type which will include performance (slowness) related tickets. Contractor Service
Manager will provide these reports on agreed bi-weekly basis and as per other support
Measurement deliverables outlined in this document.
Tool/Source Data In addition, these reports will be provided both monthly and quarterly during the M&S
Period of Performance. Agency Staff and other designated users of Microsoft
TFS/DevOps where tickets are recorded and worked through, will have access to the
tool to view the details of these tickets.
Low Volume
N/A
Eligible
Continual
Improvement N/A
Eligible
Designation KPI
SLR Credit
N/A
Percentage
SCHEDULE 3 – SERVICE LOCATIONS
Location Name Purpose U.S. State/Region
KNOWiNK LLC, HQ General Administration Missouri
KNOWiNK Location #2 Application Development and Delivery South Dakota
General Administration and Project

INEXL Consulting, HQ Salem, Oregon
Management
INEXL Location #2 Analysis and Project Activities South Dakota
Page 90 of 148
Western Region:
Microsoft Azure Government Cloud Hosting Services  Arizona
 Texas
SCHEDULE 4 – CONTRACTOR PERSONNEL
Role Name Contact Information
Project Executive Brandon Campea Email: [email protected]
Ashish Puri Ph: 503.779.8525

Project Manager (Implementation)
(subcontractor) Email: [email protected]
Ashish Puri Ph: 503.779.8525

Service Manager (M&S)
(subcontractor) Email: [email protected]
Development Lead Joe Faddoul Email: [email protected]
Cyber Security Lead James Fry Email: [email protected]
Functional and Testing Lead Laura Heckman Email: [email protected]
Training and OCM Lead Nissa Burger Email: [email protected]
Jay Varner
Data Analysis and Implementation Lead Email: [email protected]
(subcontractor)
Kevin Kumpf
Technical Analysis and Interface Lead Email: [email protected]
(subcontractor)
Page 91 of 148
SCHEDULE 5 – AGENCY PERSONNEL
Role Name Responsibilities Email

 Ensures contract requirements are
being met and enforces contract
provisions, when necessary.
 Reviews invoices and obtains Agency
approvals for payments, or otherwise
Agency Contract Bryan notifies Contractor of
invoice/payment issues. [email protected]
Administrator Edgerton
 Request assistance or clarification
from the Procurement Specialist on
contract matters or additional
procurement needs related to the
project.
 Develops the Agency’s project plan,
manages the work breakdown
structure and schedule for the
Agency; Agency documents, and
Bryan
Agency PM escalates issues. (Same as above)
Edgerton
 Manages project risks.
 Ensures all stakeholders are
communicated to and all project
deadlines are met.
 Project Management support for

Assistant PM Tim Esau [email protected]
Agency PM.
 Technical analyst responsible for

Lead Systems Analyst Brent Cecil [email protected]
completing project work.
 Individual responsible for overseeing

and ensuring the project meets
election business needs and
requirements.
Elections SME and Summer
 Lead Subject Matter Expert (SME) for [email protected]
Product Owner Davis
project work.
 Accountable for ensuring adequate
documentation of business &
technical requirements
 Consulting resource for the Agency
Contract Administrator.
 Reviews change requests to ensure
Phillip
Procurement Specialist appropriateness of amendments vs. [email protected]
Andrews
change order.
 Negotiates, drafts, and executes
amendments.
Page 92 of 148
SCHEDULE 6 – APPROVED SUBCONTRACTORS
Subcontractor Name Scope Responsibility
 Oregon Votes Implementation: MVP and Phase II

o Project management and delivery
o Requirement analysis and validation
o Functional analysis
o Data collection, analysis, testing and county and SOS
coordination.
INEXL Consulting o Interface and technical analysis
o Implementation Lead
 Oregon Votes Maintenance and Support Services
o Services Delivery Management and Reporting
o M&S Services Tier 2 Analysis and Triage
o M&S Services Tier 2 Interface Technical Analysis and Triage
o M&S Services Tier 2 Data Analysis and Triage
Microsoft Hosting Services (Azure Government Cloud)
Page 93 of 148
SCHEDULE 7 – CONTRACTOR INTELLECTUAL PROPERTY

This Schedule 7 contains and terms and conditions for the Licensed Products (listed in Part A below) (the
“License”) is effective on the Transaction Document Effective Date.
A. Licensed Products
For this Transaction Document, Contractor hereby grants to Agency a license to the following Contractor
Intellectual Property (as modified pursuant to the Services, the “Licensed Products”), pursuant to Section 11.1 of
the Agreement:
i. TotalVote
ii. TotalAddress
B. Order of Precedence; Duration

1. This Schedule 7 shall be interpreted by the following order of precedence:
i. The terms and conditions of the Agreement, less its Exhibits;
ii. Agreement Exhibit F, Federal Terms and Conditions;
iii. Agreement Exhibit B, Security and Hosting Services Requirements;
iv. Agreement Exhibit C, Insurance;
v. The terms and conditions of this Transaction Document; and
vi. This Schedule 7.
2. The license in the Licensed Products set forth in this Section 7 shall end on, and the terms of this
Schedule 7 shall survive until, the date that is the later of (i) the Transaction Document Expiration Date, or (ii)
the expiration or termination of the Agreement.
C. Enterprise License
The Parties agree that Agency’s license in the Licensed Products permits Agency to allow Counties, any of
Agency’s or Counties authorized agents (including third-party independent contractors under obligation of a
Public Contract), and any other third parties to access and use the Licensed Products; provided that Agency shall
be responsible for any use or misuse of the Licensed Products by such Counties, authorized agents, and third
parties.
D. License Grant and Acceptable Use

Provided Agency is not in default of its obligation to pay the software licensing fees specified in Part D of the
SOW, Contractor shall grant Agency a limited subscription-based, non-exclusive, irrevocable, royalty-free, world-
wide license to access and use the Licensed Products, and to authorize third parties, including Counties, to do
the same, for Agency’s Elections-related business purposes.
E. Malicious, Mischievous, or Destructive Programming

i. The Contractor warrants that the Licensed Products as delivered by the Contractor do not contain any
viruses, worms, Trojan Horses, or other malicious or destructive code to allow unauthorized intrusion
upon, disabling of, or erasure of the Licensed Products (each a “Virus”).
Page 94 of 148
ii. The Contractor shall be liable for any damages incurred by the Agency including, but not limited to, the
expenditure of Agency funds to eliminate or remove a computer virus or malicious, mischievous or
destructive programming that results from the Contractor’s failure to take proactive measures to keep
virus or malicious, mischievous or destructive programming from originating from the Contractor or any
of its employees, subcontractors or consultants through appropriate firewalls and maintenance of anti-
virus software and security updates (such as operating systems security patches, etc.).
iii. In the event of destruction or modification of any Licensed Products, the Contractor shall eliminate the
virus, malicious, mischievous, or destructive programming, restore the Agency’s software, and be liable
to the Agency for any resulting damages.
F. Entire Agreement
This License, in combination with this Transaction Document and the Agreement, constitute the entire
agreement with respect to the License for the Licensed Products. The parties agree that the terms of this License
supersede and take precedence over the terms included in any quote, terms of any shrink-wrap agreement
included with the Licensed Products, terms of any click through agreement included with the Licensed Products
or any other terms purported to apply to the Licensed Products.
Page 95 of 148
SCHEDULE 8 – THIRD PARTY INTELLECTUAL PROPERTY [RESERVED]
Page 96 of 148
SCHEDULE 9 – REQUIREMENTS
A. Personas Table
Term Description
The Oregon Secretary of State serves as the chief election officer in the
State of Oregon, which includes verifying statewide initiatives and
Agency referenda for the ballot and set up of State-wide elections. OR SoS
defines voter registration policies and procedures and holds the data
list of record for statewide voter registration.
Any staff of the Oregon Office of the Secretary of State that performs a
Agency Staff
voter registration or elections related task.
Counties maintain a list of voters residing in their County, are the

County Elections Offices authorized voter registration officer, deliver accurate elections and
process petitions for local contests.
Any staff of a County that performs a voter registration or elections

County Elections Staff
related task.
Oregon residents who are voters or potential voters; these actors

Public User
include any Public Users that may access the public online portal.
When “Staff” is referenced, these actions could be taken by either State

Staff or County staff. Staff may have multiple roles and system rights when
using the System.
B. Functional Requirements
Online Portal
Capability – Online Portal
No. Functional Requirement Description
The System shall allow the Public User to choose a language for the voter’s voter
1.01 registration application (English, Somali, Chinese, Russian, Vietnamese, or Spanish) and
provide the voter with an online application in the selected language.
1.02 The System shall facilitate for the management and implementation of additional languages.
Page 97 of 148
The System shall remember the user’s language selection as part of their application and
1.03 subsequent voter profile for potential use in other services such as providing notices and
election material to the user.
The System shall provide a way for the Public to change their language selection at any
1.04
time.
The System shall display important information that may be relevant to the Public at the
time of starting a voter registration application, including but not limited to:
 State-wide election definition information including title, date, and deadlines for new
registration applications or updates such as address and political party preference
status changes.
 Type of updates that can be made with this application, such as registering for the
first time (if proof of citizenship is already on file with Oregon Department of Motor
Vehicles --Oregon DMV) or updating specific registration information.
1.05  Link to obtain voter’s current registration information (see Perform Self-Service
Inquiry Use Case).
 Overview of the voter registration application process including eligibility criteria to
register to vote.
 Links to apply with a paper State or National form
 Links for the process to apply under the Oregon Application to Exempt Residence
Address from Disclosure as a Public (see Manage Secured Voter Use Case).
 Links to apply as a UOCAVA voter (see Apply as UOCAVA Voter Use Case).
 Links to apply as a voter with a disability and needing additional assistance.
The System shall inform the Public user of the following eligibility requirements:
 Must be a Resident of Oregon
1.06
 Must be a Citizen of the United States of America
 At least 16 years old
1.07 The System shall allow voters 16 years or over to register
The System shall have the capability of keeping voter records in an Inactive status in the
1.08
System until voter’s 18th birthday
The System shall inform the voter that their voter record will remain in an Inactive status
1.09
until their 18th birthday
The System shall ask the Public to answer questions regarding voter qualifications,
including but not limited to:
1.10
 US citizenship status
 Age
The System shall ask the Public user for a limited amount of personal information so the
System can attempt to make a potential match if the user is already in the System and verify
1.11
the user’s information with OR DMV, including but not limited to:
 First name, middle name, last name, suffix
Page 98 of 148
 Date of birth
 OR DMV Number
The System shall first require an Oregon Driver’s License, Permit, or Identification Number
1.12
issued by the OR DMV.
The System shall notify the user that the voter registration process must be completed by
mail or by appearing in-person at the local County Elections Office, if the OR DMV Number
1.13
is not recognized by the System or does not have a digital signature image associated with
it.
The System shall notify the voter if the last four of the SSN cannot be recognized but allow
1.14
the voter to continue with registration as eligible to vote in only State and Local elections.
The System shall generate a Notice to the voter with instructions on how to provide further
1.15
proof of citizenship.
The System shall generate a Notice to the voter that they are eligible to vote in only State
1.16
and Local elections until proof of citizenship is verified.
The System shall verify if the Public user has already submitted a voter registration
1.17
application or is already registered.
The System shall display the Public user’s voter registration information and current
1.18
registration status, if the Public user has already registered to vote.
The System shall display the same information available in the Perform Self-Service Use
1.19
Case under the Verify My Voter Registration service.
The System shall allow the Public user to update their previous voter registration
1.20
information, as needed, if the user has already applied or is registered.
The System shall verify if the Public user’s personal information matches with the
1.21
information on file with OR DMV.
The System shall verify if OR DMV has the last four-digits of the voter’s SSN or other proof
1.22
of citizenship for the user if the System determines a match with OR DMV’s information.
The System shall inform the user that the voter registration form can be printed to apply by
1.23 mail with proof of citizenship or appear in-person to a local County Elections Office with
proof of citizenship for voter registration.
The System shall inform the Public User if no match was made between the information
1.24
they provided and OR DMV records
The System shall inform the Public User if OR DMV does not have proof of citizenship for
1.25
the user.
Page 99 of 148
The System shall inform the Public User if OR DMV does not have an SSN match for the
1.26
user.
The System shall allow voters to print out the Voter Registration Form and mail it in with any
1.27
acceptable proof of citizenship documentation, directly to their County Elections Office.
The System shall display OR DMV information for the following, if the System determines a
match with OR DMV’s information and determines OR DMV has proof of citizenship:
 Public user’s residential address for verification, including the full address.
1.28
 Applicant’s selection of whether their residential address is the same as their mailing
address.
 Mailing address if different than the residential address.
The System shall receive any address changes from OR DMV address changes if the user
1.29
indicates on OR DMV that they want their voter registration address changed.
The System shall allow Public Users to log in and opt-out of automatic address changes
1.30
triggered by the OR DMV.
The System shall ask the Public User for their mailing address, if the user selects that their
1.31
mailing address is different than their residential address.
The System shall determine in real-time if the new address entered by the voter is a valid
1.32
address by checking against the System’s address file.
The System shall allow the Public User to enter different values for the mailing address than
1.33
the residential address fields.
The System shall have the capability to record non-standard addresses such as but not
1.35
limited to narrative descriptions of location.
The System shall have the ability to allow Public Users to select from a list of pre-identified,
1.36
non-standard residential addresses.
The System shall have the capability for a Public User to indicate their residence on a map
1.37
in the case of not having a street address.
The System shall have the capability to capture the voter’s residential address’s X/Y
1.38
coordinates on a map.
The System shall require an indication of residential address for each applicant, whether
their residential address is the same as their mailing address, and a mailing address if
1.39
different than their residential address prior to completing an application for voter
registration.
The System shall allow Public Users to update their residential address within the same or
1.40
to a different Oregon county.
1.41 The System shall store historical mailing addresses for a voter.
Page 100 of 148

The System shall display the Public User's different preferred mailing address for the voter
1.42
on the public portal after their identify has been verified.
The System shall allow the Public User to verify their current mailing address in their current
1.43
registration.
The System shall allow the Public User to manage their different preferred mailing
1.44
addresses including editing, deleting, and adding the different mailing addresses.
The System shall allow the Public User to select one of the mailing addresses on the voter’s
1.45 record displayed to them to update their current mailing address for the upcoming election
(i.e. to receive their ballot).
The System shall allow Public Users to select from the major, approved parties, and have
1.46
the ability to select Other with a text entry from the Public User.
The System shall require, if Other party preference is selected, the Public user to provide a
1.47
text entry for the party preference.
The System shall request the Public User to select a party preference before submitting the
1.48
voter registration application.
The System shall allow the Public User to indicate the following information:
 State or country of birth
 Telephone number
1.49  Former name (if applicable)
 Willingness to work at a ballot drop site on election day (yes/no)
 Willingness to work at a County office on a temporary basis (yes/no)
 Email address
The System shall require the Public User to consent to OR DMV sending the OR Secretary
1.50 of State (Agency) an electronic copy of the signature from the Public user’s OR DMV
Driver’s License, Permit, or ID.
The System shall require the Public User to swear or affirm that the information provided is
1.51
correct and that they meet the eligibility criteria.
The System shall allow an authorized Staff User to configure a time value for the System to
1.52
determine if a voter signature is old or not.
The System shall allow Staff Users to generate a Notice to voters requesting an optional
1.53 new wet signature to be submitted if the voter signature is past the time value set in the
System.
The System shall allow a User with the appropriate access/privilege to manually indicate
1.54
that a signature is old or otherwise needs to be replaced and to indicate a reason.
Page 101 of 148

The System shall have the capability to allow the Public Users that match with OR DMV
1.55 records to digitally attest the online application without providing a new copy of their hand-
written signature.
The System shall have the capability to allow Public Users to provide an electronic
1.56
signature, in the case that chooses to implement this option in the future.
1.57 The System shall validate that all required fields are completed.
The System shall inform the Public User that their application is not complete and not allow
1.58 the submission of the incomplete application, the System determines that a required field is
not completed.
1.59 The System shall save the new voter registration application.
The System shall verify with the Electronic Registration Information Center (ERIC) data that
1.60
the Public User is not deceased (see Manage Deceased Use Case).
The System shall verify that the Public User’s given date of birth complies with the voting
1.61
age requirements as defined by the Oregon SoS and/or County Election Officials.
1.62 The System shall verify that the Public User’s given residence is within the State of Oregon.
The System shall verify that the Public User’s given residence is not at a state correctional
1.63
facility or county jail.
The System shall update the potential voter’s record to indicate that they are potentially
1.64 ineligible to vote so the local County Elections Office can make a final determination of
eligibility, if the System determines the Public User is potentially ineligible to vote.
The System shall provide a confirmation receipt to the Public User. (See Issue Notices Use
1.65
Case).
The System shall provide the Public User a unique transaction number on the confirmation
1.66
receipt.
The System shall allow the Public User to search the transaction number any time after the
1.67
transaction number is issued to view the status of their voter application.
The System shall allow Staff to view the voter application record by searching the
1.68
transaction number in the System.
The System shall send the Public User a confirmation email if the Public User provided an
1.69
email and opted-in to receive emails.
The System shall send the user a SMS text message if the user provided a mobile phone
1.70
number and opted-in to receive SMS text messages.
1.71 The System shall allow the Public User to print their confirmation from the Online Portal.
Page 102 of 148

The System shall display the Public User’s current voter registration information and status
1.72
from the voter registration System.
The System shall identify the source of the voter registration applications, including but not
1.73 limited to SoS.Oregon.gov website and other State departments or community-based
organizations.
The System shall verify the residential address in their current voter registration application
as an eligible address to be registered at and make the voter Active, if the Public User was
1.75 identified to be in custody after being convicted of a felony (e.g. Inactive for reason of being
in prison for a felon) and/or registered at an address that identifies them as being in custody
(e.g. in probation for a felony).
The System shall allow a user with appropriate permissions to create a new language
1.76 option on the public portal and upload translated text for the corresponding public
instructions and voter registration application.
The System shall allow a Public User to download a printable registration application in the
1.77
language of the Public User's preference.
The System shall allow a Public User to specify if they have any special ballot requirements,
1.78
such as large print, or ADA compliant ballots.
The System shall attempt to find a potential match of the voter personal information entered
2.01
with current voter registration information.
The System shall display a message to the user that no match was found and to contact
2.02 local County Elections Office or Oregon Secretary of State's Elections Division, if the
System cannot find a match.
The System shall display at least the following information, if the System cannot find a
potential match:
 Notice to the user that no match was found and to contact and/or local County
2.03
Elections Office.
 The option to apply for or update the voter registration information (see View and
Manage Voter Use Case).
The System shall display at least the following, if the System finds a potential match with the
Public user's identifying information:
 The voter registration information of the voter.
 Name, County, address (residential and mailing if applicable), party, voter ID, date
2.04 registered, congressional district, legislative district, precinct.
 Voter history.
 Status of last ballot / election (counted or not).
 Last election voted.
 Temporary / Volunteer worker (or not).
Page 103 of 148

 A link for the user to update the voter registration information (see View and Manage
Voter Use Case).
The System shall display the following information, if the System cannot find a potential
match with the user's identifying information when requesting a sample ballot:
 Information to the user that no match was found, with contact information for local
2.05
County Elections Office; and/or
 The option to apply for or update the voter’s voter registration (see View and
Manage Voter Use Case).
The System shall display the sample ballot of the user, including the contests on that ballot
2.06 and the qualified candidates of each contest, if the System finds a match with the voter's
identifying information.
The System shall display the voter registration information that matches the information
entered by the System:
2.07
 Status & Reason (See Manage Provisional Ballots Use Case.)
 If Provisional Ballot was rejected, the System shall display a reason for rejection.
The System shall display the voter’s ballot drop site if a potential match is made with the
2.08
entered personal information.
2.09 The System shall have a mobile-friendly version of the self-service portal.
The System shall have data persist from one screen to another when data fields are the
2.10
same, so the user does not have to do the same data input on multiple screens.
The System shall have the ability to integrate with a website (such as democracy work or
2.11 acceptable equivalent) to allow the Agency’s office to export and import data on ballot drop
site locations.
The System shall have the ability to request the user to enter required information in order
2.12 to find the voter’s ballot drop site. This could include but is not limited to: County, last name,
address, date of birth, voter ID or OR DMV Number.
The System shall have the capability of receiving and sending information from the OR
2.13
DMV in real-time.
The System shall have the capability to allow Public Users to sign a candidate petition, in
2.14
the case that the State chooses to implement this option in the future.
The System shall notify the user that this is based on the voter’s current voter registration
2.15 and shall provide the option to update the voter’s voter registration (see View and Manage
Voter).
The System shall present a list of common services that may include but are not limited to:
2.16  Verifying voter registration;
 Find my ballot drop site;
Page 104 of 148

 Find any ballot drop site;

 View my sample ballot;
 Verify ballot status (including absentee and provisional ballots);
 Cancel Registration (see View and Manage Voter Use Case);
 Apply or Update Voter Registration (see View and Manage Voter and Apply as
UOCAVA Voter Use Cases);
 Respond to Correspondence (see Process Responses to Notices Use Case);
 Candidate Portal;
 Candidate Filing;
 Create Petition; (see Create Candidate and Political Party Petitions Use Case)
 View state-wide and local election information; and
 Perform Petition actions.
The System shall produce printer-friendly pages of inquiry results for Public to be able to
2.17
print a well-formatted document.
2.18 The System shall provide the nearest ballot drop site associated with that location.
2.19 The System shall require the user to enter an address, cross street, or click on a map.
The System shall require the user to enter certain information in order to find the voter’s
2.20 Provisional Ballot. This could include but is not limited to: County, election, first and last
name, voter ID, voter registration application transaction number.
The System shall require the user to enter certain information in order to find their sample
2.21 ballot. This could include but not limited to: County, last name, date of birth, voter ID or OR
DMV number.
The System shall require the user to enter required information in order to find the voter
2.22 registration record. This could include but is not limited to County, last name, date of birth,
voter ID or OR DMV Number.
The System shall allow the public to select which petition, initiative, or referendum type they
3.01 want to submit from a pre-configured list of options including, but not limited to: Statewide
initiatives, local initiatives, recall petitions, create candidate or political party.
3.02 The System shall allow the public to electronically complete the application forms.
The System shall allow the public to upload scanned documents or images of any required
3.03
forms, such as a signature sheet, to be attached to their application.
The System shall allow the public to determine if they want to submit the application
3.04
electronically, or if they want to print a copy of the application and manually submit it.
The System shall provide the public a printable pdf of the application if they choose to
3.05
submit manually.
Page 105 of 148

The System shall create a user account for the applicant if they choose to file the
3.06
application electronically.
The System shall allow a user to identify their preferred method of communication, including
but not limited to:
 Sending and Receiving notifications through the online portal
3.07  Email
 SMS Text
 Phone Number
 Mail
The System shall have the ability to process payments for applications which have fees
3.08 associated with them, such as a candidate filing fee or a petition for voter’s pamphlet fee, if
the user chooses to submit the application electronically.
The System shall provide the public the ability to review their application prior to submitting
3.09
electronically.
The System shall provide the public the ability to navigate to any portion of the application
3.10
prior to submission to edit / update the application and attachments.
The System shall provide the user to ability to track the status of the application via the
3.11
portal by logging in to the System using the user account associated with the application.
The System shall allow the user to receive and respond to notifications from Staff (i.e., that
3.12 the form was filled out improperly, the content must be updated, or that a petition is
approved for circulation).
The System shall allow the applicant to use a pre-existing account when submitting the
3.13
application if the user already has an account in the online portal.
The System shall have the ability for a petition, initiative, or referendum to be associated
3.14 with multiple user accounts, to ensure that all Chief petitioners associated with a petition
have visibility into the application.
The System shall have the ability for users to submit additional forms related to a pre-
3.15 existing petition, initiative, or referendum (i.e. signature sheets or updated application
content).
The System shall not require the public user to be a registered voter to submit an
3.16
application through the online portal.
The System shall not require Chief petitions associated with a petition to be registered
3.17
voters.
The System shall have the ability to integrate with NIC payment processing or a similar
3.18
service to process payments.
Page 106 of 148

The System shall allow the user to apply or update their voter registration to respond to the
notice, if the notice requires the Public user to verify and update their voter registration
application short of providing a new wet signature:
4.01  The System shall update the corresponding outstanding notice status when a new
voter registration application or update is received for the given potential voter.
 The System shall have the capability for Public users to upload images to satisfy
their response to a notice.
The System shall direct the user to contact their local County Elections Office if the notice
4.02 requires the Public user to respond in a way that cannot be completed online. For example
by filling out a paper voter application in-person or by mail with their proof of citizenship.
5.01 The System shall provide the public a list of standardized reports available for purchase.
5.02 The System shall allow the public to select one or multiple reports they which to purchase.
The System shall allow the public to pay the necessary fees associated with the report
5.03
types they selected.
5.04 The System shall allow the public to download their purchased reports.
6.01 The System shall provide the ability for the public to navigate to a public inquiry webpage.
The System shall allow the Public to select the recipient of the inquiry from a configurable
6.02 drop-down menu, which includes, but is not limited to, the Agency’s office and each of the
local County Elections Offices.
The System shall allow the public to enter their information, including but not limited to: First
6.03
Name, Last Name, Mailing Address, Phone Number, Email Address.
The System shall allow the public to specify their preferred communication method including
6.04
but not limited to: Email, Mail, Telephone.
6.05 The System shall allow the public to describe their inquiry in a text box.
The System shall allow the public to submit their inquiry and receive a confirmation
6.06
message via email or their preferred communication type that the inquiry was received.
The System shall have the ability to route the inquiry to a work queue for the agency
6.07
specified within the inquiry.
The System shall allow the Staff to review the details of the inquiry and indicate the inquiry
6.08
is resolved once the request has been fulfilled.
Page 107 of 148

Voter Registration
Capability – Voter Registration
7.01 The System shall display a home page with work queues containing unprocessed
transactions.
7.02 The System shall have an option for County Elections Staff to select a work queue to
view unprocessed transactions related to Electronic Voter Registration.
7.03 The System shall have the capability to populate all required fields on a Voter
Registration record using the Public User’s input from the Online Portal application.
7.04 The System shall allow the user to identify the type of document that they are scanning
such as but not limited to an application or response to a notice.
7.05 The System shall have the capability to record a scanned copy of a paper voter
registration form.
7.06 The System shall have the capability to read batch scans of paper voter registration
forms.
7.07 The System shall have the capability to record a scanned copy of the applicant’s proof of
citizenship and/or residence, if provided.
7.09 The System shall allow keyboard shortcuts, tabbing, and functions to enter information
efficiently.
7.10 The System shall allow Staff to enter in the information provided on an OR state or
approved National/Federal Voter Registration Form.
7.11 If the System finds a potential match (or duplicate) with an existing record, the System
shall allow the user to update the existing record or complete processing of the new
application and then resolve the potential duplicate (see Manage Duplicates Use Case).
7.12 If the System finds a potential match with the personal identifying information on an
application, The System shall display the applicant’s existing voter registration record in
the System and give the user the option to update the information (see Manage
Duplicates Use Case).
7.13 The System shall allow County Elections Staff to add a new person to the System.
7.14 The System shall attempt to match the personal information with OR DMV’s records and
retrieve any proof of citizenship, addresses, OR DMV’s record of last four digits of SSN
and signature, in real-time.
7.15 The System shall check the OR DMV System to verify the accuracy of name and date of
birth and shall check AAMVA for the Last 4 Digits of SSN, if the application does not have
a OR DMV number or does not find a potential match with OR DMV’s information.
Page 108 of 148

7.16 The System shall have the capability to verify the age of the signature on file and if the
signature is deemed to be old then the System shall have the capability to allow a notice
to be sent to the user to request a new voter registration wet signature (see Issue Notices
Use Case).
7.17 The System shall allow County Elections Staff to determine if the signature is not
readable.
7.18 The System shall allow County Elections Staff to indicate what signature will be the
signature of record for the voter registration record.
7.19 The System shall display the proof of citizenship and any supporting documents provided
to establish proof of citizenship.
7.20 The System shall check the OR DMV System to verify the accuracy of name, date of
birth, and Last 4 Digits of SSN, if the application does not have an OR DMV number or
the System does not find a potential duplicate (See Use Case for Manage Duplicates)
with OR DMV’s information,
7.21 The System shall allow Staff to indicate their determination of whether the applicant is a
citizen or not, or if proof of citizenship is still required for a determination.
7.22 The System shall allow Staff to indicate if a voter has not met citizenship qualifications but
still allow voter to be registered as a only State and Local voter.
7.23 The System shall clearly mark the voter record as a only State and Local voter if the
registered voter has not met HAVA requirements.
7.24 The System shall flag the voter record as a only State and Local voter to allow only State
and Local ballots to be sent and counted for the voter.
7.25 The System shall allow County Elections Staff to enter in all address information
provided.
7.26 The System shall allow County Elections Staff to determine in real-time if the address
entered by the voter is a valid address by checking against the System’s address file or
USPS.
7.27 The System shall have the capability to record non-standard addresses such as but not
limited to narrative descriptions of location. The System shall display the applicant’s
indication of their residence on a map for the case in which they do not provide a street
address.
7.28 The System shall attempt to identify the applicant’s street address of their residence from
the applicant’s indication of their residence on a map and display the potential residential
street address to Staff.
7.29 The System shall allow County Elections Staff to create a new residential address point
and record latitude / longitude coordinates for non-standard addresses.
Page 109 of 148

7.30 The System shall have the capability to determine, in real-time, a potential voter’s
precinct and assign the voter that precinct in the System.
7.31 The System shall be able to store residential addresses based on geographic location
that do not have street addresses.
7.32 The System shall attempt to identify a district and precinct for each residential address.
7.33 The System shall provide Staff with the System’s current record of the applicant’s
eligibility to vote, if any, and the reason associated with that determination.
7.34 The System shall record County Elections Staff’s determination of an applicant’s eligibility
to register to vote in Oregon and reason for that determination.
7.35 The System shall record the date the electronic application was submitted online by the
applicant.
7.36 The System shall allow County Elections Staff to record the date the paper form was filled
out by the applicant.
7.37 The System shall save the date on which an applicant’s voter registration eligibility status
was determined.
7.38 The System shall allow County Elections Staff to indicate if the applicant is a secured
voter (see Manage Secured Voter Use Case).
7.39 The System shall allow County Elections Staff to indicate if the applicant is a UOCAVA
eligible voter. (See Apply as UOCAVA Voter Use Case)
7.40 The System shall allow County Elections Staff to indicate the type of UOCAVA voter,
such as but not limited to; military or overseas citizen. (See Apply as UOCAVA Voter Use
Case)
7.42 The System shall allow Staff to enter all information that may be provided on a
Federal/National voter registration application. (See the National Voter Registration Act
page published on the Oregon Secretary of State Office’s website).
7.43 The System shall not allow the recording of race or ethnic group from a Federal voter
registration application.
7.44 The System shall allow County Elections Staff to indicate that an applicant is only eligible
to vote in state elections and add the applicant to the register of eligible voters in only
State and Local elections.
7.45 The System shall allow County Elections Staff to mark voter records as a Confidential
Voter.
Page 110 of 148

7.46 The System shall notify County Elections Staff that an update to a voter registration
record may satisfy a response to a notice if the voter registration record has an
outstanding notice.
7.47 The System shall allow County Elections Staff to clearly flag that a voter requires special
assistance.
7.48 The System shall allow County Elections Staff to notate voter record with comments
specific to special assistance required by voter (e.g., signature-by-stamp, alternate form
ballot, etc.)
7.49 The System shall have the capability of uploading to and downloading information from
the national Electronic Registration Information Center (ERIC) and the OR DMV.
8.01 The System shall allow the user to select the preliminary voter registration from a work
queue of motor voter registrations within the 21-day response period.
8.02 The System shall allow users to scan a copy of the DMV voter registration form.
8.03 The System shall have the capability to recognize pre-defined form types, provided the
forms contain a Form ID barcode.
8.04 The System shall allow the user to update the registered voter’s political party preference
(See Use Case for View and Manage Voter) or modify the voter registration in
accordance with information on the form.
8.05 The System shall have the capability to route the voter registration to the appropriate
County work queue once the application has been updated by Agency Staff.
8.06 The System shall have the capability to route the voter registration to the appropriate
County work queue, if no voter registration card is received within 21 days, to allow
County Elections Staff to complete the voter registration.
8.07 The System shall have the capability to allow County Elections Staff to complete the voter
registration by saving the voter registration record as a non-affiliated voter, if no voter
registration card is received within 21 days.
8.08 The System shall have the ability to automatically activate a voter record with the party
affiliation of Non-affiliated, after 21 days
9.01 The System shall allow Public users to apply online to be a military or overseas voter.
9.02 The System shall display important information that may be relevant to the Public at the
time of starting a UOCAVA voter registration application, including but not limited to:
 State-wide Election Definition information including title, date, and deadlines for
new registration applications or updates such as address, political party
preference, and voter status changes.
 Link to obtain voter’s current registration information (see Perform Self-Service
Inquiry Use Case).
Page 111 of 148

 Overview of the UOCAVA voter registration application process including eligibility

criteria to register to vote.
9.03 The System shall allow Public users to indicate if they want to register to vote.
9.04 The System shall allow Public users to indicate if they want to request an Absentee ballot.
9.05 The System shall allow Public users to indicate if they want to receive information on the
upcoming election.
9.06 The System shall allow Public to enter their full name and date of birth.
9.07 The System shall allow the Public user to enter their Oregon residential addresses.
9.08 The System shall determine their Oregon County based on their Oregon address.
9.09 The System shall allow mailing addresses to be formatted for military or overseas
addresses.
9.10 The System shall allow the Public User to enter in a valid email address and
communication preferences.
9.11 The System shall have the ability for the Public user to print their registration, so that they
may mail or fax the UOCAVA voter registration application to the appropriate local
Oregon Elections Office or email to [email protected].
9.12 The System shall have the ability for the Public user submits their request online directly
from the online registration.
9.13 The System shall have the capability to send the request to the appropriate County
Elections Office Electronic Voter Registration work queue.
9.14 The System shall have the capability to allow County Elections Staff to indicate a
determination on a request from a military or overseas voter.
9.15 The System shall allow County Elections Staff to establish secured electronic
communication with a military or overseas voter to receive electronic copies of
paperwork, including but not limited to; a voter registration application, proof of citizenship
or Absentee ballot.
9.16 The System shall allow County Elections Staff to register a voter as UOCAVA with a
signature image.
9.17 The System shall display the Public user’s current voter registration information and
status.
9.18 The System shall direct UOCAVA voters interested in obtaining information on upcoming
elections to the online self-service information first (see Perform Self-Service Inquiry Use
Case).
Page 112 of 148

9.19 The System shall allow applicants deemed to be U.S. citizens who never resided in the
U.S. to indicate they have a parent or legal guardian, spouse, or dependent that is
currently registered to vote in Oregon and become eligible to vote in Oregon.
10.01 The System shall display a home page to County Election Staff with a dashboard of
summary information relevant to the user’s role.
10.02 The System shall have an option for County Elections Staff to process a FPCA for voter
registration.
10.03 The System shall have the capability to record a scanned copy of a paper voter
registration forms.
10.05 The System shall have the capability to recognize the voter's email address.
10.06 The System shall record the voter’s preference for communications.
10.07 The System shall allow County Elections Staff to enter in the information provided on a
paper FPCA form.
10.08 The System shall attempt to match the information with OR DMV’s records and validate
any proof of citizenship, addresses and signature.
10.09 The System shall allow County Elections Staff to record the voter’s email.
10.10 The System shall allow Staff to clip the signature file from the FPCA and attach the image
to the voter record.
10.11 The System shall allow Staff the option to save the entire FPCA card and attach the
image to the voter record.
10.12 The System shall display the applicant’s residential address.
10.13 The System shall provide County Elections Staff with the System’s current record of the
applicant’s eligibility to register to vote, if any, and the reason associated with that
determination.
10.14 The System shall record Staff’s determination of an applicant’s eligibility to vote in Oregon
and reason for that determination.
10.15 The System shall identify applicants for UOCAVA as a UOCAVA voter.
10.16 The System shall save the date on which a UOCAVA applicant’s voter eligibility status
was determined.
10.17 The System shall add the applicant to the registry of eligible voters if the applicant was
determined to be eligible to vote.
10.18 The System shall have the ability to indicate if a FPCA application matches a voter
already in the System.
Page 113 of 148

10.19 The System shall provide County Elections Staff the option to confirm that the records
match, and if confirmed updated the existing voter record
10.20 The System shall provide County Elections Staff the option to confirm that the records
match, and if it is not confirmed by County Staff, to create a new voter record
10.21 The System shall allow applicants deemed to be U.S. citizens who never resided in the
U.S. to indicate they have a parent or legal guardian or spouse, that is currently
registered to vote in Oregon and become eligible to vote in Oregon.
11.01 The System shall have an option for County Elections Staff to process a FWAB.
11.02 The System shall have an option for Staff to issue a notice to voters based on receipt or
in response to an FWAB.
11.03 The System shall allow Staff to generate notices from templates or provide the option to
manually type in specific text.
11.04 The System shall allow County Elections Staff to update a voter’s history that a FWAB
ballot was received, the manner in which the ballot was received (email, mail, drop off,
etc.) and the time frame of the vote (early, on Election Day, late, etc.) (See Use Case for
Receive Ballot Envelopes / Signature Validation).
11.05 The System shall have the capability to recognize and record email addresses and the
voter’s preference for communications
11.06 The System shall allow County Elections Staff to process UOCAVA ballots received
electronically such as by email or fax server.
12.01 The System shall allow the County Elections Staff to enter ACP voter registration System,
prior to processing the corresponding a new voter registration application by County
Elections Staff or updating a non-ACP voter as a new ACP Voter (see View & Manage
Voter Information Use Case).
12.02 The System shall allow the County Elections Staff to indicate an existing voter registration
record as an ACP secured voter, prior to processing the corresponding the new voter
registration form.
12.03 The System shall now consider the voter as an ACP secured voter once County Elections
Staff flag an existing voter registration as an ACP voter.
12.04 The System shall restrict access to ACP voters’ address information (residence
addresses) from the public and users with public access rights.
12.05 The System shall remove ACP voters from reports that include voter details but not from
reports with statistics only, per statutes.
12.06 The System shall allow Staff to view the work queue of unprocessed secured voters (ACP
& Confidential) with residence related fields hidden.
Page 114 of 148

12.07 The System shall allow County Elections Staff to mark a voter record as a Confidential
Voter (i.e. Secured but non-ACP).
12.08 The System shall create a voter registration notification card to send to ACP and
Confidential voters which does not include the actual residential address nor the precinct
(see Issue Notices Use Case).
12.09 The System shall check new voter registration applications from OR DMV to identify if
they are flagged as being an ACP member.
12.10 The System shall flag if a new OR DMV voter registration application or update is for an
ACP voter.
12.11 The System shall alert County Elections Staff if a Confidential voter has requested an
update to the voter record.
12.12 The System shall only allow certain users with authorized access rights to view the
residential addresses of secured voters.
12.13 The System shall not display voter registration records for ACP voters to non-authorized
users.
13.01 The System shall generate a notification to the Confidential voter that an update is
pending upon a newly signed State Elections Form or a secured authorization through the
Online Portal.
13.02 The System shall have an option for County Elections Staff to select unprocessed
transactions within work queue to update and complete application.
13.03 The System shall keep UOCAVA voters as Active UOCAVA voters until the Staff has
made an update to the voter record to change this status, upon request of the voter and
as necessary.
13.04 The System shall verify if the applicant has already applied or is registered.
Manage Registry
Capability – Manage Registry

14.01 The System shall present a list of fields that can be used to search for voter information.
These voter identification fields include but are not limited to:
 Voter ID;
 Voter name, including a phonetic match or “sounds like” name;
 Date of birth;
Page 115 of 148


 Oregon driver license number or non-operating Identification Card number (OR DMV
Number);
 Last 4-digits of Social Security Number;
 Residence or mailing address;
 Telephone number;
 Email address;
 County (provide note that this will restrict results to this County);
 Effective date of registration change, Valid from data, Registration date;
 Activity (e.g., name or address changes performed on the voter record);
 Party affiliation;
 Citizenship;
 Source of registration (e.g., OR DMV, Online Portal, in-person, mail); and
 Voter districts (e.g., answers to the questions: which house/senate district am I in?).
14.02 The System shall allow wildcard characters (an asterisk “*” or percent sign “%”) to be used
in text fields to search for text that begin or end with specific characters.
14.03 The System shall allow searches to be restricted to a specific status, so that Staff can
restrict the list of records that are displayed for a search.
14.04 The System shall provide results for all counties if County is not entered.
14.05 The System shall display a list of possible voter matches to the search criteria.
14.06 The System shall have the ability to search for the County of the user or other Counties if
the user requests a wider search.
14.07 The System shall provide results for all counties if a specific County is not entered.
14.08 The System shall display information about voters. For example, voter information may
include:
 All search criteria where there is voter information;
 Effective date of registration change;
 Voter ID;
 Voter status (includes Active/Inactive, Federal-only);
 Precinct number;
 Ballot drop site;
 Provisional ballot status;
 Name of voter;
 Voting history of the voter;
 Activity (e.g., name or address changes performed on the voter record);
 Notes (narrative or attached image files);
 Party affiliation;
 Citizenship;
 Source of registration (e.g., Motor Voter, Online Portal, in-person, mail);
 Attached documents;
 Valid from date or Effective data of change;
 Registration date; and
 Voter districts (e.g., answers to the questions: which house/senate district am I in?).
Page 116 of 148


14.09 The System shall display tasks associated with a voter record such as but not limited to:
 Manage Deceased status.
 Manage Felon status.
 Record signature verification findings.
 Other Pending tasks associated with the voter that require Staff interaction to resolve
(see Use Cases: NCOA & County Transfers, Manage Secured Voter, Manage
Duplicates, Process Returned Mail).
14.10 The System shall allow County Elections Staff to update any information on a potential
voter’s registration and history (see Use Cases for NCOA & County Transfers, Manage
Secure Voter, Manage Duplicates, Returned Mail, Issue Notices, Manage Notices, Process
Voter Registration Application, Provisional Ballots, and Process Deceased, and Process
Felon for specific updates that Staff may make to a potential voter’s record).
14.11 The System shall allow County Elections Staff select the option to cancel a voter registration
(see Use Cases: NCOA & County Transfers, Manage Duplicates, Returned Mail, Manage
Deceased, Manage Felon).
14.12 The System shall require County Elections Staff to indicate a reason for voter registration
cancellation.
14.13 The System shall cancel a voter registration and remove the potential voter from the list of
eligible voters.
14.14 The System shall allow County Elections Staff to determine if a cancelation notification will
be issued.
14.15 The System shall allow the County Elections Staff to add cancelled voters to the queue for
notice generation (see Use Case for Issue Notices).
14.16 The System shall allow County Elections Staff to print labels, including but not limited to
voter mailing address labels and ballot label.
15.01 The System shall import and export electronic updates with the Electronic Registration
Information Center (ERIC) on deceased individuals through an interface with ERIC.
15.02 The System shall have the ability to receive electronic updates from the Oregon Health
Authority (OHA) on deceased individuals through an interface with OHA, should the Agency
choose to implement this integration in the future.
15.03 The System shall have the capability to record the date of death.
15.04 The System shall attempt to identify potential matches of records and information on
deceased individuals.
15.05 If the System finds a potential match between the applicant and a deceased individual, The
System shall automatically update the potential voter’s record as being deceased, add any
additional information to the voter’s record from DHS’ information, automatically remove the
voter from the roll of voters and add them to the queue for records that need to be
processed for notice generation (see Use Cases for View & Manage Voter and Issue
Notices).
15.06 The System shall identify potential matching records if only part of the personal identification
information matches such as: Name, date of birth, OR DMV Number or last 4 digits of SSN.
Page 117 of 148


15.07 The System shall display a queue of deceased records that need to be processed.
15.08 The System shall have the ability for County Election Staff to review records marked as
deceased and confirm the record is a match or indicate the records do not match.
15.09 The System shall automatically update the voter’s status upon the County Election Staff
indicating the voter is deceased.
15.10 The System shall remove the records from the queue of deceased to be processed once
County Elections Staff indicates the record is not a match to a record in the System.
15.11 The System shall allow County Elections Staff to review information related to deceased
records to determine if any match existing records.
15.12 If a record is updated, the System shall automatically update the record with the deceased
information and the record may be added to the queue for notices to be generated (see
Issue Notices use case).
15.13 The System shall allow the County Elections Staff to manually enter a record of a deceased
individual.
15.14 The System shall attempt to identify potential matches, cancel voters, and notify County
Staff to work the queue of notices to issue when deceased records are added to the
System.
15.15 If the System does not find a potential match, the System shall add new records of
deceased to the work queue of deceased for County Elections Staff to work.
15.16 The System shall allow County Elections Staff to reinstate a voter’s voter registration, for
example in the case a voter was deemed to be deceased and then it is found that the voter
is not actually deceased.
15.17 The System shall allow County Elections Staff to flag a deceased voter record as not
deceased.
15.18 The System shall require County Elections Staff to document the justification for flagging a
deceased record as not deceased and forward the record to a supervisor for review and
approval.
15.19 The System shall allow a County Elections Supervisor to review deceased voter records
flagged as not deceased, the justification for the flagging, and either approve or deny the
requested change.
16.01 The System shall receive updates from Oregon & U.S. District Courts on those incarcerated
due to a felony conviction.
16.02 The System shall attempt to identify potential matches between the applicant and the
incarcerated felons.
16.03 If the System finds a potential match between a potential voter and an incarcerated felon,
The System shall automatically update the potential voter’s record as being incarcerated,
add any additional information to the voter’s record from the courts’ information,
automatically remove the voter from the roll of voters and add them to the queue for records
that need to be processed for notice generation (see Use Cases for View and Manage Voter
and Issue Notices).
Page 118 of 148


16.04 If the System finds a potential match between an applicant for voter registration and an
incarcerated felon, then the System shall add them to the queue for records that need to be
processed for notice generation to confirm if their voting rights have been restored. (See
Use Case for Issue Notice).
16.05 The System shall display a queue of incarcerated felons voter records that need to be
processed.
16.06 The System shall have the ability for County Election Staff to review records marked as
incarcerated and confirm the record is match or indicate the records to do not match.
16.07 The System shall automatically update the voter’s status upon the County Election Staff
indicating the voter is incarcerated.
16.08 The System shall update the status of the records from the queue of deceased to be
processed once County Elections Staff indicates the record is not a match to a record in the
System.
16.09 The System shall allow County Staff to review information related to incarcerated records to
determine if any match existing records.
16.10 If a record is updated, then the System shall automatically update the record with the
incarcerated information and the record may be added to the queue for notices to be
generated (see Issue Notices use case).
16.11 The System shall allow the County Elections Staff to manually update a voter record of an
incarcerated felon.
16.12 The System shall attempt to identify potential matches, suspend voters, and notify County
Elections Staff to work the queue of notices to issue when felon records are added to the
System.
16.13 If the System does not find a potential match, then the System shall add new records of
incarcerated felons to the work queue for County Elections Staff to work.
16.14 The System shall allow Staff to reinstate voting rights to the voter by updating the voter
record.
17.01 The System shall identify soft matching records as potential duplicates if only part of the
personal identification information matches based on a configurable set of fields and
thresholds such as name, date of birth, OR DMV number or last 4 digits of SSN.
17.02 The System shall identify potential matching records based on a configurable set of fields
and thresholds such as full last name, first 5 characters of first name, DOB, OR DMV
number & last 4 digits of SSN.
17.03 If the System identifies a potential match with a new voter registration application that would
cause the voter’s registration to change counties, then the System shall update the voter’s
registration in the new County, cancel the voter’s registration in the old County and notify
the old County of the cancelation.
17.04 The System shall display a queue of potential duplicate records, filtered for existing records
with the oldest Effective Date of Change / Registration Date State-wide, and registered
within the County that County Elections Staff is working so County Elections Staff can
cancel the voter first.
Page 119 of 148


17.05 The System shall allow authorized users to configure and define the registration date, such
as date at the time of the initial voter registration application is determined to be eligible.
17.06 The System shall allow Staff to set the parameters of the duplicate search.
17.07 The System shall identify potential matches within a County.
17.08 The System shall identify potential matches State-wide.
17.09 The System shall allow authorized users to turn off the State-wide duplicate checking.
17.10 The System shall display the details of all potential matches of multiple voter record for the
same voter in the System, including but not limited to:
 All voter record details in the System
 Full name details including previous names and aliases
 Identification numbers such as OR DMV number, SSN, etc.
 Residential addresses
 Mailing addresses
 Signatures
17.11 The System shall have an option for users to indicate their determination, and the System
shall retain that determination, of whether potential duplicate records match or not.
17.12 The System shall also maintain a history of all previous voter registration information for the
new voter record.
17.13 The System shall add the record to the queue of records for which notices need to be
generated. For example, a cancelation notice may need to be generated (see Use Case for
Issue Notices).
17.14 If the County Elections Staff indicates that the records do not match, then the System shall
maintain the records separately.
17.15 The System shall allow the County Elections Staff to take no action on resolving the
duplicate and still issue a notice for more information (See Use Case for Issue Notices).
17.16 The System shall allow County Elections Staff to update a potential duplicate case with the
action they took short of resolving the duplicate. In this case the County Elections Staff may
request more or a confirmation of information by issuing a notice (see Use Case for Issue
Notices).
17.17 If County Elections Staff works on a potential duplicate but does not resolve the duplicate,
the System shall update the queue of potential matches with what has been worked on or
not.
17.18 The System shall identify potential matches at time of data entry between potential new
voter records and existing voter records based on the configurable definition of potential
matches (see definition of potential matches in Manage Duplicates Use Case).
17.19 The System shall automatically merge potential match duplicate records and provide a
record of the merge activity.
17.20 The System shall accept information from the Counties that duplicate records within
Counties have been merged and that the person is still registered within the County. When
Page 120 of 148


duplicate records are merged, the System shall reduce the number of registered voters but
not increase the number of canceled voters.
18.01 The System shall allow County Elections Staff to make mass updates.
18.02 The System shall provide County Elections Staff with multiple types or options of mass
updates to make, such as but not limited to:
 Cancelling all voter registrations for inactive individuals that have not voted in the
last two federal elections and are in inactive status;
 Cancelling all voter registrations that have had their address found to be invalid;
 Canceling outstanding tasks and updating application status for applicants that have
been issued a Notice of Incompleteness and no response has been received within
a given time period;
 Redistricting;
 Zip code changes; and
 Precinct changes.
18.03 The System shall allow the user to verify the mass update prior to making it in the System
such as through previewing the changes or testing the update in a test database.
18.04 The System shall provide Staff the option of reviewing the changes prior to the changes
being applied.
18.05 The System shall allow County Elections Staff to make mass updates to multiple records at
one time.
18.06 The System shall allow County Elections Staff to generate new notices based on mass
updates (see Use Case for Issue Notices).
18.07 The System shall allow County Elections Staff to undo any mass update that has been
previously made in the System.
18.08 The System shall allow for the Staff to undo the specific parameters of the mass update, so
as not to undo any other updates made in the System.
19.01 The System shall allow County Elections Staff to search for voter records (See Use Case for
View and Manage Voter).
19.02 The System shall allow County Elections Staff to update the status of the voter record.
19.03 The System shall allow County Elections Staff to notate the reason for the status change as
Returned Mail.
19.04 The System shall allow County Elections Staff to generate new notices (see Use Case for
Issue Notices).
20.01 The System shall receive updates from OR DMV, USPS, and Electronic Registration
Information Center (ERIC) on address change information.
20.02 The System shall attempt to identify potential matches between potential existing voter
records.
20.03 If the System finds a potential match for the voter record, then the System shall update the
potential voter’s record with the updated address, add any additional information to the
voter’s record from information received from OR DMV, USPS, or ERIC, automatically move
Page 121 of 148


the voter to the correct County and add them to the queue for records that need to be
processed in the new County Elections work queue.
20.04 The System shall provide County Elections Staff the ability to review the queue of potential
matches to determine if a matching record exists within the System.
20.05 The System shall provide County Elections Staff the ability to sort the queue of potential
matches using any criterion available in the queue.
20.06 If a potential update is determined as a match by the user, then the System shall
automatically update the record with the new address information and the record may be
added to the queue for notices to be generated (see Issue Notices use case).
20.07 If the address change is within the same County, then the System shall log the activity, mark
the transaction as processed, and remove the record from the unprocessed work queue.
20.08 The System shall have the ability to assign a County to a voter record based on voter
registration residential address fields.
20.09 The System shall have the ability to route voter records to the appropriate work queues
based on assigned voter record County.
20.10 The System shall allow the County Elections Staff to manually update a record of an
individual.
20.11 The System shall allow County Elections Staff to reinstate a voter’s voter registration
address and status previously in their County.
21.01 If the County Elections Staff identifies a matching record, then the System shall allow them
to cancel the voter (see View & Manage or Cancel Voter use case).
21.02 The System shall identify soft matching records if only part of the personal identification
information matches such as: Name, date of birth, OR DMV Number or last 4 digits of SSN.
Notices
Capability – Notices

22.01 The System shall have an option for Staff to issue a notice.
22.02 The System shall display a queue of records for which notices need to be created.
22.03 The System shall have the capability to prioritize requirements to issue notices.
22.04 The System shall allow Staff to modify the priority of requirements to issue notices.
22.05 The System shall create various types of notices for various reasons, including but not
limited to:
 Notice of confirmed voter eligibility including voter registration card;
 Notice of incomplete or illegible information voter registration information;
Page 122 of 148


 Notice informing voter of changes made to their voter record (e.g., address change,
status changes, etc.) (see use cases in the Manage Register section);
 Notice requesting Registration Update Needed or Confirmation in the case of
potential voters deemed deceased;
 Only State and Local Notice – A notice to the voter that they are registered as “only
State and Local voter”, meaning that they did not provided proof of citizenship (e.g.,
DMV ID, SSN, etc.) and therefore may only vote for State and local offices;
 Notice requesting potential address update based on different address provided on
petition compared to registration record; and
 Notice that a voter’s ballot envelope was challenged or rejected.
22.06 The System shall allow Staff to issue second notices in the case first notices were returned
as undelivered or the time since the first notice without any update has exceeded a defined
period.
22.07 The System shall record what notice template and version was used to create the potential
voter specific notice.
22.08 The System shall allow the user to email notices to potential voters.
22.09 The System shall allow for a voter record to be marked as “opt-out of emails”.
22.10 The System shall allow for a voter record to be marked as “opt-out of text messages”.
22.11 The System shall allow the user to print notices to be mailed to potential voters.
22.12 The System shall allow the user to print one notice at a time.
22.13 The System shall allow the user to print a batch of notices at a one time.
22.14 The System shall allow the user to create an extract of notices to be printed for 3rd party
printing.
22.15 The System shall have the capability to export a mail merge file.
22.16 The System shall allow Staff to send a text message (SMS) to voters.
22.17 The System shall allow Staff to rank a voter’s communication preferences within the voter
record.
22.18 The System shall allow Staff notices to be sent to potential voter’s email address on file
based on notice type.
22.19 The System shall be capable of producing notices tailored to County specific requirements
such as but not limited to local County contact names and elections office location based on
System parameters.
22.20 The System shall allow County Elections Staff to produce notices to be generated in PDF,
or a word processing format (such as MS Word) based on the notice.
22.21 For ACP and Confidential – The System shall not include Residential address on notices.
23.01 The System shall allow Staff users to manage notices.
23.02 The System shall allow user to create notice templates.
Page 123 of 148


23.03 The System shall allow Staff to create notices using 3rd party productivity tools such as,
Microsoft Word or Google Docs.
23.04 The System shall allow Staff to specify a retention period for the notification type.
23.05 The System shall allow Staff to create notices using functionality inherent to the System.
23.06 The System shall allow Staff to specify a name for the template.
23.07 The System shall display a list of templates available.
23.08 The System shall allow Staff to filter the list of templates by name, description, or other
attributes associated with templates.
23.09 The System shall allow Staff user to select the template notice they want to update.
23.10 The System shall allow County Elections Staff to manage the pre-existing format and
content of notice templates.
23.11 The System shall allow Staff to set review time periods for notices to generate a second
notice once the time period has lapsed with no response to the first notice.
23.12 The System shall allow Staff to specify which notices a particular template is the default
template for (for example, the default change of address notification template).
23.13 The System shall allow each County to create their own County specific templates.
23.14 The System shall allow Counties to share their County specific templates, allowing other
Counties to utilize them.
23.15 The System shall have the ability to save templates for future use.
23.16 The System shall be able to create notices template with static content.
23.17 The System shall be able to create notices template with dynamic content based on data
from specific voter records.
23.18 The System shall maintain a historical record of all notices sent to a registered voter.
23.19 The System shall have the ability to automatically purge notifications that are beyond the
defined retention period for that notification type.
23.20 The System shall allow Staff with appropriate user access rights to archive notice templates.
23.21 The System shall have the ability to uniquely identify notices including versions of each
notice and retain older versions.
24.01 The System shall allow users to process responses to notices.
24.02 The System shall provide a queue of voters who were sent notifications requiring resolution.
24.03 The System shall provide the ability for Staff to search for a notification by, but not limited to:
 Voter Name;
 Notification Type;
 Address; and
 Voter ID.
24.04 The System shall update the corresponding outstanding notice status when a new voter
registration record or update is received for the given potential voter.
Page 124 of 148


24.05 The System shall update the corresponding outstanding notice status when a voter provides
a replacement or provisional ballot.
24.06 The System shall allow Staff to indicate receipt of a response to a notice and the information
provided in the response.
24.07 The System shall allow Staff to close an outstanding or pending notice when a response to
a notice is received.
Manage Jurisdictions
Capability – Manage Jurisdictions

25.01 The System shall allow Staff to manage geographic information in the System.
25.02 The System shall display a summary of geographic information in the System including but
not limited to information that has been uploaded or modified, date, time and user that
uploaded or modified data.
25.03 The System shall allow Staff to update geographic and projected coordinates.
25.04 The System shall allow Staff to update parcel information.
25.05 The System shall allow Staff to update zip code information with the plus 4 zip code.
25.06 The System shall allow Staff to update address points of residences.
25.07 The System shall have the capability to track Census block track.
25.08 The System shall allow Staff to export data in a selected format such as, but not limited to,
.csv, .txt, .xlsx, .pdf, etc.
25.09 The System shall validate that all the geographic information in an election includes all the
precincts defined for an election.
25.10 The System shall allow Staff to manage geographic information based on street file formats,
including uploading street files to make updates, and downloading geographic information in
a street file format.
25.11 The System shall allow Staff to manage geographic information based on geographic
information system (GIS) formats, such as but not limited to: Shapefile (SHP), Keyhole
Markup Language (KML), File Geodatabase (GDB) or GeoPackage, Layers (LYR),
OpenStreetMap (OSM), ArcGIS, and roster formats such as ESRI Grid.
25.12 The System shall allow Staff to upload GIS files to make updates and download geographic
information in GIS formats.
25.13 The System shall have the capability to identify residential addresses as valid residences
based on County information of assigned addresses and zoned residences.
25.14 The System shall have the capability to identify addresses as commercial addresses.
Page 125 of 148


25.15 The System shall have the capability to validate zip codes against valid zip codes including
plus 4 zip codes.
26.01 The System shall allow Staff to manage districts in the System.
26.02 The System shall display a summary of districts in the System including but not limited to
information that has been uploaded or modified, date, time and user that uploaded or
modified data.
26.03 The System shall allow Staff to manage districts, define district name, district type and any
associated jurisdictions.
26.04 The System shall allow Staff to define all the counties associated with that district.
26.05 The System shall allow Staff to define a rank or order for the districts.
26.06 The System shall allow Staff to create or modify districts in a test or development
environment.
26.07 The System shall allow Staff to stage the creation or modification of districts prior to
implementing changes.
27.01 The System shall allow County Elections Staff to manage precincts in the System.
27.02 The System shall display a summary of precincts in the System including but not limited to
number of precincts by County, information that has been uploaded or modified, date, time
and user that uploaded or modified data.
27.03 The System shall allow County Elections Staff to manage precincts, such as separate or
merge precincts / precinct parts.
27.04 The System shall allow County Elections Staff to define precinct name, type and any
associated jurisdictions or districts.
27.05 The System shall associate precincts to jurisdiction or districts.
27.06 The System shall allow County Elections Staff to import geographic boundaries drawn in a
GIS application, for the purpose of defining the geographical boundaries of a precinct. Data
affected by the GIS data import must then be queued for mass updates.
27.07 The System shall allow County Elections Staff to associate ballot drop sites to precincts.
27.08 The System shall validate that all the precincts included in an election cover all the
geographic area for an election.
27.09 The System shall allow for voter registration and ballot tally information to be reported by
precincts.
27.10 The System shall allow for Staff to highlight a district and view the precincts that are within
the selected district.
27.11 The System shall allow County Elections Staff to review precinct updates prior to them
saving them.
27.12 The System shall allow County Elections Staff to undo or reverse changes that have been
made to precincts.
Page 126 of 148


27.13 The System shall allow County Elections Staff to indicate a precinct is inactive and to
archive the precinct.
27.14 The System shall have the capability to assign visual indicators such as color or shape
coding to indicate status or potential priority.
27.15 The System shall have the capability to create precinct parts and sub parts.
27.16 The System shall allow County Elections Staff to manage precinct parts or sub-parts of a
precinct like a whole precinct.
27.17 The System shall have the capability to have different precinct parts for different elections.
27.18 The System shall allow users to update the names of geographical boundaries to comply
with standardized naming conventions.
Petitions
Capability – Petitions

28.01 The System shall provide an option for the Staff to process an application for a petition
and to specify an Initiative or Referendum petition type.
28.03 The System shall allow the Staff to indicate whether the application is for an initiative or
referendum, based on information entered by the Staff or directly obtained from the
scanned application.
28.04 The System shall have the ability to query the ORESTAR system (Oregon SoS campaign
finance system) to verify the appropriate campaign finance account for the petition has
been established.
28.05 The System shall allow Agency Staff to indicate that the Campaign Finance has been
setup.
28.06 The System shall route the transaction back to the appropriate county’s work queue once
it has been indicated that Campaign Finance setup is complete.
28.07 The System shall route to the appropriate county’s work queue as an “Unprocessed”.
28.08 The System shall allow the Staff to indicate if the application for petition is approved for
circulation.
28.09 The System shall have the ability to maintain a list of paid circulators registered with the
state.
28.10 The System shall determine the deadline for filing the circulated Initiative and
Referendum petitions based on the date of the next election.
28.11 The System shall determine the number of signatures required for the Initiative or
Referendum.
Page 127 of 148


28.12 The System shall include on the notice for an application for petition: the disposition of
the application (accepted or rejected), the date of the application, the number of
signatures required for the petition, the deadline for filing circulated petitions, and the
transaction number issued for the petition.
29.02 The System shall allow the Staff to enter in the information which may be provided on the
two Secretary of State applications for petition.
29.03 The System shall allow the unique transaction number and the petition status to be
searchable to the Candidate or Chief Sponsor through the Online Portal.
29.04 The System shall allow the Staff to indicate if the application for petition is approved.
29.05 The System shall determine the deadline for filing the circulated petitions based on the
date of the next election.
29.06 The System shall allow Staff to save formatted templates of cover sheets and signature
sheets to be printed.
29.07 The System shall determine the number of signatures required for the petition.
29.08 The System shall allow the Staff to create and modify the signatures required for
petitions.
29.09 The System shall include on the receipt for an application for petition: the disposition of
signatures required for the petition, the deadline for filing circulated petitions, and the
transaction number issued for the petition.
30.01 The System shall provide an option for the Staff to process an application for a petition
and to specify a Recall petition type.
Recall applications for petition.
30.04 The System shall allow the Staff to indicate that the application is for a state or local
Recall, based on information entered by the Staff or directly obtained from the scanned
application.
30.05 The System shall allow the Staff to indicate if the application for a Recall petition is
approved for circulation.
30.06 The System shall determine the deadline for filing the circulated Recall signatures.
30.07 The System shall determine the number of signatures required for the Recall.
the application (approved or not), the date of the application, the number of signatures
required for the petition, the deadline for filing circulated petitions, and the transaction
number issued for the referral petition.
31.01 The System shall provide an option for the County Elections Staff to process an
application for a petition and to specify a referral petition type.
31.03 The System shall allow the County Elections Staff to enter in the information which may
be provided on the applications for petition.
Page 128 of 148


31.04 The System shall allow the County Elections Staff to indicate that the application is for a
County Referral, based on information entered by the Staff or directly obtained from the
scanned application.
31.05 The System shall allow the County Elections Staff to scan and attach any maps, charts or
other graphics provided with the application for petition.
31.06 The System shall allow the County Elections Staff to enter the title, short title and text of
the referral petition.
31.07 The System shall have the ability to count words within these text fields and clearly
display the word count for the Staff.
31.08 The System shall allow the County Elections Staff to submit an application for petition.
31.09 The System shall allow the County Elections Staff to forward referral text to the Referral
filer.
31.10 The System shall allow Staff to print the Referral text.
31.11 The System shall allow Staff to email the referral text to the Referral filer.
31.12 The System shall allow the County Elections Staff to indicate if the ballot title is approved
for publication.
31.13 The System shall record the date of the Referral application, whether it is in the form of a
ballot title request or referral text.
31.14 The System shall determine the deadline for receipt of the ballot title.
31.15 The System shall allow the County Elections Staff to create and modify the deadlines of
ballot titles for Referrals.
31.16 The System shall allow County Elections Staff to assign a pending status to a Referral
31.17 The System shall allow County Elections Staff to assign a reason code and deadline for
the duration of the publication.
31.18 The System shall determine the deadline for requested circuit court review requests.
31.19 The System shall allow the County Elections Staff to create and modify the deadlines of
requested circuit review requests.
31.20 The System shall allow County Elections Staff to scan in additional documents received
during the Referral process.
31.21 The System shall allow the County Elections Staff to approve the Referral.
31.22 The System shall allow County Elections Staff to approve a Referral and assign a
measure number and add a date of election.
31.23 The System shall allow the Referral to be pulled into an election based on the entered
date of election.
searchable to the Candidate or Chief Sponsor through the Online Portal.
32.04 The System shall allow the Staff to indicate if the voter’s pamphlet content is approved.
Page 129 of 148


32.05 The System shall provide the ability for Staff to indicate if the applicant will pay the
associated fees or will gather the necessary signatures for the information to be placed in
the voter’s pamphlet.
32.06 The System shall allow the Staff to process payments if the applicant chooses to pay
fees associated with voter pamphlet content.
32.07 The System shall have the ability for issue official cover sheets and signature templates if
the applicant will be collecting signatures.
signatures required for the petition (if necessary) the deadline for filing circulated
petitions, and the transaction number issued for the petition.
33.01 The System shall have an option for the Staff to receive a circulated petition.
33.02 The System shall allow the Staff to select and receive the specific petition that was
previously created in the System.
33.03 The System shall have the capability to record a scanned copy of a petition, including all
signature logs as submitted.
33.05 The System shall be capable of determining whole sheets to be disqualified.
33.06 The System shall allow Staff to determine the parameters for disqualification.
33.07 The System shall determine the total number of signature sheets and signature lines
submitted.
33.08 The System shall be capable of determining signature lines to be disqualified on
remaining sheets.
33.09 The System shall identify the remaining signature lines of eligible electors after
determining the whole sheets and signature lines on remaining sheets that are
disqualified.
33.10 The System shall allow a receipt to be generated, stating an acknowledgement of receipt
and the number of pages.
33.11 The System shall have the ability to count the number of signature lines and determine if
the total falls within the required parameters.
33.12 The System shall allow Staff to select the type of signature sheets and parameters
required (i.e. minimum and maximum number of signatures).
33.13 The System shall allow the Staff to record the date the petition was filed and generate a
receipt of the filing with this information for the Chief Petitioner(s).
33.14 The System shall allow Staff to create a deadline after the receipt of signature sheets to
select a random sample of signature lines to be processed, based on configurable values
(e.g., 5% random sample to be selected in 20 business days).
33.15 The System shall allow Staff to create and modify deadlines for selecting the random
sample.
Page 130 of 148


33.16 The System shall allow Staff to create and modify the percentage for random sample of
signature lines.
33.17 The System shall allow Staff to have the option to bypass the random signature sample.
33.18 The System shall allow Staff to enter in the total number of petition sheets received.
33.19 The System shall allow Staff to assign sheet number to all the initial signature log sheets
received.
33.20 The System shall allow Staff to create, maintain & view a list of registered paid
circulators.
33.21 The System shall have the capability to allow Staff to view a list of volunteer circulators
and contacts.
33.22 If the sheets are already in the System, then the System shall allow Staff to view scanned
images of the sheets and any automatic determination made by the System regarding
each sheet.
33.23 The System shall allow Staff to disqualify petition sheets, indicate the specific sheet
number disqualified and a reason for sheet disqualification.
33.24 The System shall update the number of remaining petition sheets based on the sheets
that have been disqualified.
33.25 The System shall allow Staff to select a disqualification reason from a common list of
values or enter a reason that is not listed inside a freeform text field.
33.26 The System shall allow the Agency’s System Administrator to determine a set of values
for common disqualification reasons to be shown in the dropdown field.
33.27 The System shall allow Staff to choose a disqualification reason from a dropdown list of
values.
33.28 The System shall allow Staff to enter a reason that is not on the pre-determined list of
reasons.
33.29 If the signature lines of each sheet are already captured in the System, then the System
shall allow Staff to view scanned images of each signature line of the remaining sheets
and any automatic determination made by the System regarding each signature line.
33.30 The System shall allow Staff to indicate in the System that specific signature lines are
disqualified, remove the specific lines from further processing and indicate a reason for
signature line disqualification.
33.31 The System shall allow Staff to indicate the number of remaining signature lines and
disqualified signature lines per sheet.
33.32 The System shall determine the total number of remaining signatures for the petition from
all the remaining sheets.
33.33 The System shall compare the total number of signatures remaining to the number
required for the petition.
Page 131 of 148


33.34 If the System identifies the total number of signatures remaining is greater than or equal
to the number required for the petition, then the System shall indicate if the petition still
valid pending the random sampling of the remaining signatures.
33.35 If the System determines the total number of signatures remaining is less than the
number required for the petition and the deadline for submitting signatures has not
passed, then The System shall deem the petition pending for not having enough
signatures and notify the Chief Petitioner(s).
33.36 The System shall allow Staff to generate a Notice to the Chief Petitioner(s) of the
insufficient number of signatures required for the petition.
33.37 If the System determines the total number of signatures remaining is less than the
number required for the petition and the deadlines for signature submissions has passed,
then the System shall deem the petition failed for not having enough signatures after
receiving petition.
33.38 The System shall allow Staff to generate a Notice of the failed petition for the Chief
Petitioner(s). (See Use Case for Issue Notices)
33.39 The System shall allow Staff to update the status of the petition.
33.40 The System shall allow Staff to indicate the petition sheets have been reviewed and are
ready for the creation of random sample of eligible signatures.
33.41 The System shall allow Staff to enter and record any other notes applicable to the
processing of the petition or signature logs in a freeform text field to track historical
comments.
33.42 The System shall record the date and time of comments and notes entered by Staff in the
text field.
33.43 The System shall allow Staff to record key information from any communication with
petitioners regarding a specific petition, including but not limited to approximate date of
when petition sheets will be delivered, the number of sheets and signature lines in each
batch.
34.01 The System shall allow Staff to create a random sample for signature verification for a
specific petition with a percentage of the total number of remaining eligible signatures for
verification.
34.02 The System shall record what sheet number and line number have been randomly
selected for verification.
34.03 If the signature log sheets and signature lines of the petition are in the System, then the
System shall indicate the signature lines for verification. The System shall identify the
sheets that contain signature lines for verification.
34.04 If the signature log sheets and signature lines of the petition are not in the System, then
the System shall allow Staff to indicate the sheets that contain signature lines and the
signature lines for verification.
35.01 The System shall allow Staff to record signature verification findings.
35.02 The System shall allow Staff to view the randomly selected signature lines to be verified.
Page 132 of 148


35.03 The System shall allow Staff to view the randomly selected signature lines for verification
at the same time they are viewing voter registration information.
35.04 The System shall allow Staff to record the results of signature verification for each
signature line.
35.05 If the signature line is verified, then the System shall allow Staff to update the voter
registration record of the signer with the history that they signed the given petition.
35.06 If the signature line is disqualified, then the System shall allow Staff to indicate a reason
for the signature line disqualification.
35.07 The System shall allow Staff to indicate that a signature verification is pending based on
a review.
35.08 The System shall allow Staff to check signature lines as many times as deemed
necessary.
35.09 The System shall allow Staff to require a different Staff user for double or triple checks.
35.10 The System shall allow Staff to certify or finalize the results of their line-item signature
verification.
35.11 The System shall indicate to Staff how many signature lines have been verified, and how
many have been disqualified, pending or any other status.
35.12 The System shall determine the total number of disqualified signatures from each set of
line-item signature verification.
35.13 The System shall allow Staff to lock down petitions after the challenge period has been
completed and the jurisdiction has certified the petition for local petitions.
35.14 The System shall allow Staff to report on signature verification findings during the
challenge period for petitions.
35.15 The System shall allow Staff to generate a Notice to the Chief Petitioner(s) or Candidate
informing the signature verification findings (See Use Case for Issue Notices)
35.16 The System shall have the capability for County Elections Staff to manage configurable
values of Staff hourly rates and estimated hours worked.
36.01 The System shall allow Staff to determine the final disposition of a petition.
36.02 The System shall determine the percentage of signatures found to be invalid from the
random sample.
36.03 The System shall apply the percentage of signatures found to be invalid from the random
sample to the signatures for verification and determine the number of signatures for the
whole petition that are likely valid.
36.04 The System shall compare the total number of signatures that are likely to be valid from
the whole petition to the number of signatures required for the petition.
36.05 The System shall allow Staff to close or finalize a petition and report the results.
36.06 If the System determines that the likely number of remaining valid signatures is greater
than or equal to the number required for the petition, then the System shall deem the
Page 133 of 148


petition as having a sufficient number of signatures for the matter to be placed on the
ballot.
36.07 The System shall be capable of generating a notice to the Governor if a petition is
deemed to have a sufficient number of signatures for the matter to be placed on the
ballot.
36.08 If System determines that a sufficient number of signatures have been submitted for a
recall, then The System shall allow Staff to set a pending disposition for the recall and set
a deadline for the Public Official resignation before processing further.
36.09 If the System determines that the likely number of remaining valid signatures is less than
the number required for the petition, then the System shall deem the petition as not
having a sufficient number of signatures for the matter to be placed on the ballot.
36.10 The System shall generate a notice if a petition is deemed to have a sufficient number of
signatures for the matter to be placed on the ballot.
36.11 In either case of the final disposition of the petition, the System shall generate a notice to
the Chief Petitioner(s) or political committee that applied for the petition with the final
counts and results of the signature verification as compared to the number of signatures
required for the petition and final disposition of the petition. (See Use Case for Issue
Notices)
37.01 The System shall allow the Staff to indicate the type of petition being entered, based on
information entered by the Agency Staff or County Elections Staff or directly obtained
from the scanned application.
37.02 The System shall allow the Staff to issue a notice to the applicant of application for
petition.
37.03 The System shall allow the Staff to scan and attach any maps, charts or other graphics
provided with the application for petition.
37.04 The System shall allow the Staff to submit an application for petition.
37.05 The System shall allow the unique transaction number and the Petition status to be auto
filled in Notice and petition receipt templates.
searchable to Agency Staff and County Elections Staff.
searchable to the Chief Petitioners through the Online Portal.
37.08 The System shall create a unique transaction number for the petition.
37.09 The System shall generate a unique transaction number for each Petition application
filed.
37.10 The System shall have the capability to record a scanned copy of a paper application for
petition.
37.11 The System shall provide an option for the Staff to process an application for a petition.
37.12 The System shall record the date of the application.
Page 134 of 148


37.13 The System shall send the unique transaction number for the Petition to Agency work
queue for setup in the ORESTAR Campaign Finance System.
37.14 The System shall allow the Staff to create and modify the filing deadline of circulated
petitions.
37.15 The System shall allow the Staff to create and modify the number of signatures required
for petitions.
applications for petition.
37.17 The System shall allow the Staff to enter the title, short title and text of the petition.
Elections Management
Capability – Election Management

38.01 The System shall allow Staff users to define State-wide elections.
38.02 The System shall allow Staff users to define local elections and specify the specific districts
the local election includes.
38.03 The System shall allow Staff users to define a name and description for an election.
38.04 The System shall allow Staff to define, copy and modify an election specific calendar
including but not limited to election date & time, early voting dates, deadlines for
registrations and early ballots, and UOCAVA dates.
38.05 The System shall allow Staff to view a combined calendar for the System including but not
limited to Oregon holidays, dates, times, and deadlines for all elections defined in the
System.
38.06 The System shall allow Staff to define what districts are included in an election definition.
38.07 The System shall allow Staff to define what Counties are included in an election definition.
38.08 The System shall allow Staff to view precincts included in an election definition and notify a
County that a possible change or update is needed.
38.09 The System shall identify the precincts to be included in an election based on the district
and Counties included in the election.
38.10 The System shall allow Staff to select what parties are participating in the election for
partisan elections.
38.11 The System shall allow Staff to define what type of State-wide election (e.g., general,
primary, special election, special congressional district election, recall election).
38.12 The System shall propagate election definitions to all relevant Counties.
Page 135 of 148


38.13 The System shall allow County Elections Staff to further define state-wide elections for their
County and complete the County election definition set up process for elections that are a
part of state-wide elections.
38.14 The System shall allow County Elections Staff users to define election details of local-only
elections such as but not limited to date, time, early voting dates, and deadlines for
registrations.
38.15 The System shall allow County Elections Staff to define the districts for a local election.
38.16 The System shall identify precincts for a local election based on districts for the election.
38.17 The System shall allow County Elections Staff to define precincts for a local election.
38.18 The System shall allow County Elections Staff to define the type of election and if a partisan
election pick the parties participating in the election.
38.19 The System shall allow County Elections Staff to define and/or identify drop off locations.
38.20 The System shall allow County Elections Staff to define that Federal-only voters are not
eligible for local elections.
38.21 The System shall allow County Elections Staff to manage cross county elections.
38.22 The System shall identify all the unique ballot styles for the election based on the election
definition, districts or jurisdictions and precincts.
38.23 The System shall allow Staff to close an election after the end of a challenge period.
38.24 The System shall allow Staff to re-open an election that was previously closed after the
challenge period.
38.25 The System shall allow County Elections Staff users to further define the definition of all
elections, except they will not be able to modify what defines.
38.26 The System shall allow certain authorized users to make changes to any election definition.
38.27 If defines a local election that includes a district that goes into another County, then the
System shall notify both Counties of the election set up and to further define the local
election in their County.
38.28 The System shall allow the local County election definition to include what districts and
jurisdictions apply to the election, which may not include whole counties.
38.29 The System shall only propagate State-called elections to counties that have include some
part of a district or jurisdiction defined in the State-wide election.
39.01 The System shall allow County Elections Staff to manage drop-off locations.
39.02 The System shall allow County Elections Staff to add a drop-off location to the System.
39.03 The System shall require County Elections Staff to enter various information to create a
drop-off location such as but not limited to:
 Drop-off location name or identification (the location’s address);
 Type of location and in what phase of the election the location can be used (could be
one or multiple) (e.g. County office, early voting, election day, both, replacement
ballot site);
Page 136 of 148


 Contact information such as contact person, phone number and email address;
 Accessibility such as Americans with Disability Act (ADA) compliant locations;
 If location is not ADA compliant, include details to make the site ADA compliant;
 Upload images and be able to print them.
39.04 The System shall allow County Elections Staff to view all information associated with a drop-
off location including but not limited to drop-off locations, location information, precincts,
district, workers associated with the location, and voting history of the location.
39.05 The System shall allow County Elections Staff to modify or deactivate whole polling
locations or vote centers.
39.06 The System shall allow County Elections Staff to export drop-off site location information
into a file including, but not limited to tabular address for each location, X/Y coordinates for
each location.
40.01 The System shall allow County Elections Staff to manage ballot styles.
40.02 The System shall automatically generate a list of unique ballot styles that are needed in
order to have the correct contests appear on the ballot for every given precinct / precinct
part, district, election, party for partisan elections, and type of voter such as Federal-only.
40.03 The System shall allow Staff to generate a report of all the ballot styles in the election.
40.04 The System shall define ballot styles with a unique identifier, the precincts that are valid for
the ballot style, the districts on the ballot style, and the party for the ballot style.
40.05 The System shall allow County Elections Staff to view a list of unique ballot styles.
40.06 The System shall allow County Elections Staff to add, modify, merge, or delete ballot styles.
40.07 The System shall allow County Elections Staff to add and modify measures, initiatives,
referendums, recalls, or any other petition type to a ballot style due to them being processed
and verified outside of the System.
40.08 The System shall validate that all the precincts for an election have assigned ballot styles.
40.09 The System shall allow County Elections Staff to update the ballot styles unique identifiers
generated from the System to the ballot style identifiers used for printing or tabulation.
40.10 The System shall allow County Elections Staff to indicate that the list of ballot styles has
been verified or is valid.
40.11 The System shall automatically mark the list of ballot styles as invalid or needing to be
verified whenever geographic information, polling locations, or districts are modified in the
System.
40.12 The System shall allow Staff to lock down an election definition and ballot styles so that no
further changes can occur to districts or precincts that would affect ballots styles.
40.13 The System shall allow County Elections Staff to import a list of ballots styles for an election
that also may include the unique identifiers from the tabulation systems.
40.14 The System shall update the list of ballot styles for an election based on an imported list of
ballot styles.
Page 137 of 148


40.15 The System shall create Federal-only ballot styles that will only include federal races or
contests based on election type.
40.16 The System shall create City/Town only ballot styles for partisan party elections with only
City / Town races or contests.
40.17 The System shall support the creation of alternative ballot style formats such as large print,
or formants necessary to comply with ADA requirements.
41.01 The System shall allow County Elections Staff to manage election workers.
41.02 The System shall allow County Elections Staff to view all potential and previous election
workers for a given precinct or polling locations (see Generate Report use case for various
election work reports).
41.03 The System shall allow County Elections Staff to view all voter registration information for
registered voters that indicated they want to be election workers on their application.
41.04 The System shall allow County Elections Staff to view the detailed information associated
with an election worker.
41.05 The System shall display detailed information for election workers, including but not limited
to:
 Election worker ID, OR DMV number or Voter ID;
 Name, date of birth, last 4 digits of SSN;
 Residential & mailing address;
 Phone numbers, email address;
 Party;
 Skills, training, certifications;
 Languages fluent;
 Whether the election worker is not invited to return and associate reason why;
 Whether the election worker is disabled or not and may have a service animal;
 Roles (e.g. previously assigned role, current assignment);
 Preferred precinct;
 Preferred city;
 Whether the election worker wants to be paid or not;
 Notes;
 Election worker history;
 Status (e.g. potential, active/confirmed, previous);
 Election assignment (of previous and future assignment);
 Rates of pay for different roles or certifications;
 Mileage traveled;
 Related to another election worker;
 Whether a County employee; and
 Other information.
41.06 The System shall allow County Elections Staff to add potential election workers.
Page 138 of 148


41.07 The System shall attempt to match new potential election workers with applicants for voter
registration and allow Staff to edit their information including updating the willingness to be
an election worker on Election Day.
41.08 The System shall allow County Elections Staff to view a list of potential election workers not
already assigned to a location that are available to work the particular election.
41.09 The System shall allow County Elections Staff to send a notification to potential volunteers
through the online portal or registered voters email, if they have an email of file.
Process Elections
Capability – Process Elections

42.01 The System shall allow County Elections Staff to select the registered voter who needs a
printed ballot.
42.02 The System shall allow for individual voters to be selected or for a batch of voter records to
be selected based on criteria.
42.03 The System shall allow County Elections Staff to specify if the ballot is a physical printed
copy, or an electronic ballot.
42.04 The System shall allow County Elections Staff to indicate if an envelope needs to be printed
for that ballot, and if an envelope will not be printed the ballot must contain a scanner.
compatible barcode that allows County Staff to scan the ballot to associate it with the correct
voter and section for the voter to sign.
42.05 The System shall allow County Elections Staff to indicate if the envelope needs to be
compatible with envelope scanners.
42.06 The System shall allow County Elections Staff to print the relevant ballot and envelope.
42.07 The System shall allow for an individual ballot and envelope to be printed or a batch of
ballots and envelopes to be selected for printing.
42.08 The System shall allow County Elections Staff to select the registered voter who needs and
electronic ballot.
42.09 The System shall allow County Elections Staff to specify if the electronic ballot shall be
exported to an external file, sent to the voter through the online portal or, if the registered
voter has an email on file, directly to the voter’s email address.
43.01 The System shall allow County Elections Staff to process receipt of a provisional ballot.
43.02 The System shall allow County Elections Staff to record information provided on the outside
of a provisional ballot, such as recording where the provisional ballot came from.
43.03 The System shall have the capability to record a scanned copy of the outside of provisional
ballots.
Page 139 of 148

Capability – Process Elections

43.05 The System shall identify the registered voter associated with the provisional ballot.
43.06 The System shall display the voter’s hand-written signature from their voter registration.
43.07 The System shall display an image of the signature from the voter’s provisional ballot.
43.08 The System shall have the capability of comparing a hand-written signature from a voter’s
registration and from a voter’s provisional ballot, determine if the signatures match and
provide information on the potential match to County Elections Staff.
43.09 The System shall allow County Elections Staff to manually indicate if a hand-written
signature matches between a voter’s registration and their provisional ballot.
43.10 The System shall allow Staff to verify addresses written on provisional ballots to addresses
that are allowed to vote in a precinct.
43.11 The System shall verify if a voter that submits a provisional ballot has already submitted an
early ballot and had the early ballot accepted.
43.12 If the System determines that a voter submitting a provisional ballot has already submitted
an early ballot, then the System shall allow County Elections Staff to indicate the disposition
of the provisional ballot that was received with the appropriate disposition code and
associated reason.
43.13 The System shall display to Staff whether an early ballot has been accepted or rejected.
43.14 The System shall require County Elections Staff to indicate a disposition of the received
provisional ballot in the System, the receipt number on the provisional ballot and a reason
for a rejected provisional ballot, such as not registered / not eligible, wrong ballot style, or
polling location.
43.15 The System shall have the capability to track the reasons why provisional ballot is being
submitted (for example: early ballot sent, wrong precinct, not registered, etc.)
43.16 The System shall require County Elections Staff to indicate a disposition of the received
provisional ballot in the System, the receipt number on the provisional ballot and a reason
for a rejected provisional ballot, such as not registered / not eligible, wrong ballot style, or
polling location.
43.17 The System shall allow County Elections Staff to indicate in the System that the provisional
ballot has been processed as a Federal Only Ballot status.
43.18 The System shall provide that status to the Public user of provisional ballots for Federal
Only status and that only the Federal races will be counted. (See use case Perform Self
Service Inquiry).
Page 140 of 148

Tabulation and ENR
Capability – Tabulation and ENR

44.01 The System shall allow County Elections Staff to process the receipt of a ballot envelope.
44.02 The System shall allow County Elections Staff to scan a barcode on a ballot envelope to
identify receipt of a ballot envelope. Note, the barcode may include the election code in
addition to the voter ID to ensure proper ballot identification.
44.03 The System shall allow County Elections Staff to utilize a ballot sorter to identify receipt of a
ballot envelope. Note, the barcode may include the election code in addition to the voter ID
to ensure proper ballot identification.
44.04 The System shall allow County Elections Staff to record in the System the manner in which
a ballot envelope was received (e.g., email, mail, drop off), location of receipt (e.g. specific
drop off location), date and time ballot envelope was received and the time frame of the vote
(e.g., early, on Election Day, late).
44.05 The System shall allow County Elections Staff to record information provided on the outside
of a ballot envelope such as the voter signature.
44.06 The System shall have the capability to record a scanned copy of the outside of the ballot
envelope such as the voter signature.
44.08 The System shall have the capability to capture the ballot envelope signature file and full
image of the ballot envelope, including affidavit.
44.09 The System shall allow Staff to select whether or not to save the signature and ballot
envelope images in the System.
44.10 The System shall have the capability of storing the ballot envelope image files in a location
that will not overload the System and causing reduced performance and speed.
44.11 The System shall identify the registered voter associated with the ballot envelope.
44.12 The System shall display an image of the signature from the voter’s ballot envelope.
44.13 The System shall have the capability of comparing a hand-written signature from a voter’s
registration to a voter’s ballot envelope, determine if the signatures match and provide
information on the potential match to County Elections Staff.
44.14 The System shall allow County Elections Staff to manually indicate if a hand-written
signature matches between a voter’s registration and their ballot envelope.
44.15 The System shall allow County Elections Staff to indicate a disposition (accepted, rejected,
or suspense) of the received ballot envelope in the System and if rejected, include a
rejection reason.
44.16 The System shall allow for County Elections Staff to designate a rejection reason.
44.17 The System shall allow County Elections Staff to add voter records to the queue to issue
notices, for example to send notices for ballot envelopes accepted or rejected (see Issue
Notices use case).
44.18 The System shall have the capability to check to ensure that ballot envelopes in a
suspended status are cleared be for the canvass has been completed.
Page 141 of 148


44.19 The System shall allow Staff to run reports of the number of ballot envelopes scanned,
received, and rejected (See Use Case for Generate Reports).
44.20 The System shall allow County Elections Staff to produce reports to be generated in a
selected format such as PDF, Excel, .csv or MS Word.
44.21 The System shall allow voter information, including signature files, to be exported to the
ballot sorter used by the County.
44.22 The System shall give an indication to Staff that this ballot envelope is for an ACP-Secured
or Confidential voter.
44.23 The System shall allow for specific System roles and access rights to be designated to
those allowed to view ACP and Confidential voters.
44.24 The System shall allow a voter record to be clearly flagged as a voter requiring special
circumstances due to disabilities.
44.25 The System shall allow Staff to enter in comments regarding the voter’s special
circumstances within the voter record.
44.26 The System shall allow for the Staff to override a rejection from the ballot sorter or hand-
scanner if the signature stamp is deemed valid.
44.27 The System shall allow for the Staff to override a rejection from the ballot sorter or hand-
scanner if the signature is deemed as a household exception.
44.28 The System shall allow Staff to flag active voter records with the same residential address to
be manually reviewed for signature when received.
44.29 The System shall have the capability to alert staff that a ballot envelope has already been
accepted and ability to override, along with being able to check activity.
45.01 The System shall allow for data to be exported in a format that can be manually and
physically transferred to the tabulation systems used by the County Offices.
45.02 The System shall allow for a data export in a format that is readable by the County
tabulation systems without manipulation.
45.03 The System shall allow for the Staff to update ballot styles (See Use Case for Manage Ballot
Styles) and export updated data, in the case the tabulation system test fails to read the
original ballot.
45.04 The System shall have the ability to interface with the tabulation system, and record the
results counted by that tabulation system.
45.05 The System shall allow Staff to run reports of the ballot tally results (See Use Case for
Generate Reports).
45.06 The System shall allow County Elections Staff to produce reports to be generated in a
selected format such as PDF, HTML, Excel, .csv or MS Word.
45.07 The System shall have the ability to log if a ballot was rejected and which ballot envelope
was rejected with an appropriate rejection reason.
45.08 The System shall allow Staff to run audit reports.
Page 142 of 148


45.09 The System shall allow Staff to select formats and parameters of reports, including but not
limited to, ballot tally by district, precinct, or ballot styles.
45.10 The System shall allow Staff to record comments of any discrepancies found in the logs of
ballot envelope and voter records data in the System during the Tally Auditing process for
historical tracking and historical reporting.
45.11 The System shall have the capability to alert Staff that a ballot has already been counted
and the ability to override, along with being able to check activity.
46.01 The System shall allow for an interface with the tabulation systems used by the County
Offices.
46.02 The System shall allow for the Staff to see the calculated results from the tabulation system
with no ties or links to individual voter records (voting must be kept anonymized).
46.03 The System shall allow for County Elections Staff to view calculated results for the election,
at any point in time during the election.
46.04 The System shall allow for County Elections Staff to run, export, and print election reports
with date and timestamps, at any point during the election.
46.05 The System shall allow County Elections Staff to enter in write-in candidates.
46.06 The System shall allow County Elections Staff to import write-in candidate information, by
way of a text, .csv, or Excel file import.
46.07 The System shall have the ability to calculate write-in votes with the counts already entered
into the System for the current election.
46.08 The System shall allow County Elections Staff to run the Abstract of Votes report.
46.09 The System shall allow County Elections Staff to select whether to show election results for
the individual county or all counties on the Abstract of Votes report.
46.10 The System shall allow County Elections Staff to certify elections.
46.11 The System shall allow County Elections Staff to run reports showing total calculations for
each candidate and contest.
46.12 The System shall have the ability to provide reporting of election results by precinct and
districts in a tabular format corresponding to GIS data.
46.13 The System shall allow County Elections Staff to export reports in a selected format such as
PDF, Excel, .csv or MS Word.
46.14 The System shall allow County Elections Staff to close elections within their County.
46.15 The System shall have the ability to mark winning candidates based on the count of votes
within the County.
46.16 The System shall allow the County Elections Staff to override the results, if necessary.
46.17 The System shall require a reason or comment if the System calculations are overridden.
46.18 The System shall mark all winning candidates with their new designated positions within the
County.
46.19 The System shall convert the election status as “Closed”.
Page 143 of 148


46.20 The System shall allow Staff to revert the election status for modifications.
46.21 The System shall allow a log of all transactions, including status changes, to be captured
with a date and timestamp.
46.22 The System shall allow County Elections Staff to assign Abstraction results to Agency work
queue.
46.23 The System shall generate a Notice to the Agency office when an Abstraction is assigned
into their work queue by a County Elections Office.
46.24 The System shall make the Abstraction results read-only and un-editable by the County
once it is assigned to the Agency work queue.
46.25 The System shall have the capability to allow County Elections Staff to pull back the
Abstraction results should the County Elections Staff choose to retract the submission to
correct an error.
46.26 The System shall allow Agency to view Abstraction results from the appropriate work queue.
46.27 The System shall allow for Agency to export Abstraction results in a selected format (e.g.,
Excel, PDF, .csv, etc.)
46.28 The System shall allow County Elections Staff to assign Abstraction results to another
County’s work queue.
46.29 The System shall generate a Notice to the Filing Officer’s office when an Abstraction is
assigned into their work queue by another County Elections office.
46.30 The System shall make the Abstraction results read-only and un-editable by the County
once it is assigned to another County’s work queue.
46.31 The System shall allow for a Filing Officer’s County to pull final Abstraction report from their
Abstraction work queue.
46.32 The System shall allow County Elections Staff to amend Abstraction results previously
submitted to the Agency work queue.
Generate Reports
Capability – Generate Reports

47.01 The System shall display options to the user to run reports on all information in the System.
47.02 The System shall allow the user to filter the report to a subset of the data based on any
information in the System.
47.03 The System shall provide multiple “canned” or pre-built reports for the user to select from
and run or modify prior to running.
47.04 The System shall allow the user to build their own ad-hoc reports based on any information
in the System.
Page 144 of 148

47.05 The System shall allow the user to schedule the time of day when a report runs.
47.06 The System shall provide the selected report in a graphical display or data table format
available for export from the System.
47.07 The System shall export report data in a format specified by the user such as but not limited
to: .csv, .xlsx, .docx, .pdf, .xml, .html, .txt.
47.08 The System shall provide multiple “canned” or pre-built reports for the user to select from
and run or modify prior to running. Canned reports may include, but are not limited to:
 VR-021 Duplicate Voters Across Counties;
 VR-005 Duplicate within County;
 DP-007 Precinct Voter Count;
 DP-012 Precinct Committee Persons;
 E-021A Election Participation by Precinct;
 BP-050 Challenged Ballots;
 BP-033 Voted not Voted;
 BP-015 Real Ballot Returns;
 E-022 Election Audit Report;
 DP-019 District Update Information Form;
 PM-007 Petition Summary Results;
 VR-014 Voter Walking List;
 E-007 Election Billing Worksheet;
 E-008 Allocation Cost Worksheet;
 SEL 237 Election Day Report.
Page 145 of 148

C. Non-Functional Requirements
No. Capability Non-Functional Requirement Description
Availability and
48.1 The System must be available with at least 99.99% uptime
Recovery
The System must meet the Recovery Point Objective guaranteed by the
Availability and
48.2 premium tier of Microsoft Azure SQL Database for standard/active geo-
Recovery
replication.
The System must meet the Recovery Time Objective guaranteed by the
Availability and
48.3 premium tier of Microsoft Azure SQL Database for standard/active geo-
Recovery
replication.
49.1 Environmental Compatible with supported version(s) of Windows Operating Systems.
Production and non-production environments for the System must be
49.2 Environmental
configured the same.
All System components (hardware and software) must use supported
49.3 Environmental
generations and versions.
Scalability and The System must be scalable to accommodate increased capacity for
50.0
Capacity voter registrations over the next 10 years.
Responsiveness of the System must be similar to that of a modern
51.1 Performance system and will be quantified during Requirements Validation (see Task 3
in Schedule 1 of this Transaction Document).
The performance of the System must not be negatively impacted by
51.2 Performance
execution of back-end processes (e.g., data exchanges).
Provided the System is not actively undergoing load or stress testing,
then the System performance must meet business user needs and not
51.3 Performance
degrade to a sub-standard performance level over time as data volumes
increase.
Interface transactions must be completed within a period of time
51.4 Performance
determined during Requirements Validation (see Task 3 in Schedule 1).
All System performance times (e.g., response times and report
51.5 Performance generation) should average the time negotiated under the resulting
Contract.
The System must have the ability to accommodate legally required
52.1 Regulatory
changes.
The System’s public portal(s) shall comply with the Web Content
Accessibility Guidelines (WCAG), including WCAG 2.0 and WCAG 2.1;
52.2 Regulatory
Section 508 of the US Rehabilitation Act of 1973; and the requirements of
the Plain Language Act of 2010.
Services for this Project will be performed by the Contractor at location(s)
52.3 Regulatory
physically located in the United States (US).
52.4 Regulatory Data must be located exclusively on servers physically located in the US.
The voter record must be able to remain within the System indefinitely
52.5 Regulatory
and be able to comply with State and County retention policies.
Page 146 of 148

The System must have the capability to adhere with Election law under
Oregon Revised Statutes, which includes but is not limited to:
 246. Administration of Election Laws; Vote Recording Systems;
 247. Qualification and Registration of Electors;
 248. Political Parties; Presidential Electors;
 249. Candidates; Recall;
 250. Initiative and Referendum;
52.6 Regulatory
 251. Voters’ Pamphlet;
 253. Absent Electors;
 254. Conduct of Elections;
 255. Special District Elections;
 258. Election Contests; Recounts;
 259. Campaign Finance; and
 260. Campaign Finance Regulation; Election Offenses.
The System must not include any components that allow third parties to
52.7 Regulatory collect voter lists. In addition, no System components shall “spam” voters
via SMS, email, or otherwise.
The System must be able to limit or detect access to critical components
53.1 Security in order to guard against loss of System integrity, availability,
confidentiality, and accountability.
All System software (including third-party software to be installed such as
53.2 Security operating systems and drivers) and installation programs must be
documented.
The System must have protections against external threats and be able
53.3 Security
to monitor and respond to those threats.
Maintenance and Support offerings must be available from the Contractor
54.1 Maintainability
and/or other support service providers.
The System has a product road map that Agency is able to provide
54.2 Maintainability feedback to influence future software development for Agency’s business
purposes.
The System must be configurable by Agency users with administrative
privileges to adapt to basic changes that are needed (e.g., updating a
54.3 Maintainability
functional setting by changing the selection from an existing dropdown
list).
The System must support full auditing and validation capability for
55.1 Auditability viewing and changing voter records, ballot tracking, and specified
election data.
Fully auditable log of voter records and election management System
55.2 Auditability records, including changes occurring throughout the lifecycle of those
records.
The System must have analytics capabilities on external interfaces, for
the purpose of knowing where and when System failures occur (e.g. in
55.3 Auditability
the event of an OMV failure, this log would help the Agency identify the
cause).
55.4 Auditability The System must support full audit history of interfacing transactions.
Page 147 of 148

The System must, to the maximum extent feasible, include fully auditable
log of ballots generated, and the changes throughout the lifecycle of
55.5 Auditability those ballots. Contractor shall document gaps between “fully auditable”
and the extent these logs are actually auditable during Requirements
Validation (see Task 3 in Schedule 1 of this Transaction Document).
The System must have the capability to provide notifications to the
55.6 Auditability appropriate personnel for anomalous activities occurring within the
System.
The System’s audit logs must be secure, fully exportable, and easy to
55.7 Auditability
interpret.
The System must be able to be extended to support new voter
56.0 Extensibility registration and election management innovations (e.g., ranked choice
voting).
Agency is the owner of the data and will remain so during the entirety of
Data Integrity and the System’s period of performance. Contractor shall not sell or otherwise
57.1
Accessibility provide the data to any other entity without the express written consent of
the Secretary.
Data Integrity and
57.2 Data to be stored in two separate physical locations.
Accessibility
Data Integrity and
57.3 The data is maintained in a manner that is protected from corruption.
Accessibility
Data Integrity and The System must provide access to all data for real-time operational
57.4
Accessibility reporting.
Data Integrity and
57.5 The System must be able to support real-time analytics and reporting.
Accessibility
The System and System operation must be transparent and fully
58.0 Transparency
documented.
System must allow for configuration, transfer, and load testing of files into
59.0 Interoperability
ballot sorters, tabulators, and other third-party systems.
D. Required Interfaces/Integrations
Contractor shall interface the System with the external systems identified and described in Agency’s RFP #S-
16500-00000053, Attachment D (Interface Use Cases), with the following modification: Use Case 2.1, Electronic
Registration Information Center (ERIC) Import, must also include exports (not just imports).
Page 148 of 148

KNOWINK Oregon Agreement

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

KNOWINK Oregon Agreement

Uploaded by

Copyright:

Available Formats

DocuSign Envelope ID: 01BC0791-8B8F-4414-87D0-37B541571261

TRANSACTION DOCUMENT No. 1

System Implementation Services

INFORMATION TECHNOLOGY MASTER SERVICES AGREEMENT 16500-00002791

1. Definitions and Construction

6.5. System Stabilization Period.

CONTRACTOR, BY EXECUTION OF THIS TRANSACTION DOCUMENT, HEREBY ACKNOWLEDGES THAT

THE STATE OF OREGON, ACTING THROUGH ITS OFFICE OF SECRETARY OF STATE

SCHEDULE 1 – STATEMENT OF WORK

1. Improve the pain points discussed above.

Guiding Principles – Future State Vision

Guiding Principle Description

Deliverable Expectation Documents

File Format Description

.pdf Portable Document Format

.docx Microsoft Word

.xlsx Microsoft Excel

.vsdx Microsoft Visio

State of Oregon Holidays

1. New Year’s Day;

C. Tasks, Deliverables, Periods of Performance, and Acceptance Criteria

 Tasks and Services to be performed;

Task 1.0 – Project Management

 Prepare and maintain the Agency’s Project Management Plan.

Deliverable(s) and Acceptance Criteria

Task 1.1 – Project Planning

Deliverable(s) and Acceptance Criteria

Contractor shall provide the following:

No. Deliverable Description Acceptance Criteria

Task 1.2 – Project Kickoff Meeting

Deliverable(s) and Acceptance Criteria

Contractor shall provide the following:

No. Deliverable Description Acceptance Criteria

Task 1.3 – Status Reports

Deliverable(s) and Acceptance Criteria

Contractor shall provide the following:

No. Deliverable Description Acceptance Criteria

Task 1.4 – Quarterly Project Scope Reviews

Deliverable(s) and Acceptance Criteria

Contractor shall provide the following:

No. Deliverable Description Acceptance Criteria

Task 2.0 – Organizational Change Management

Period of Performance: June 2021 thru February 2023.

 Identify the OCM audience, including:

Deliverable(s) and Acceptance Criteria

Task 2.1 – Gap Analysis

Deliverable(s) and Acceptance Criteria

Contractor shall provide the following:

No. Deliverable Description Acceptance Criteria

 Identify standardized to-be

Task 2.2 – Communication Plan

Deliverable(s) and Acceptance Criteria

Contractor shall provide the following:

No. Deliverable Description Acceptance Criteria

 Agency PM provides written

Task 2.3 – Training Strategy

Deliverable(s) and Acceptance Criteria

Contractor shall provide the following:

No. Deliverable Description Acceptance Criteria

Task 2.4 – Change Reinforcement Plan

Deliverable(s) and Acceptance Criteria

Contractor shall provide the following:

No. Deliverable Description Acceptance Criteria