Electronic Ballot Reader
Rosa Arias, Chad Feller,
Walter Smith
TABLE
OF CONTENTS
1 Introduction . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Functional Requirements . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Non-Functional Requirements . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Use Case Modeling . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Use Case Descriptions . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . 9
3.2 Selected Detailed Use Cases . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .11
5 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .19
6 Team Member Contributions . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 21
7 Glossary Of Terms . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8 References . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1
Introduction
Technological advancements have provided a means for the implementation of direct recording electronic (DRE) voting machines, which allow voters to directly mark their votes by means of a touch screen, push buttons, or similar device [2]. The record of the votes generated by the voter is created by the software within the voting machine, resulting in a record that is just as trustworthy as the software that produced it. The software’s ability to record and tabulate votes and maintain accurate record keeping has to be trusted. However, voters are blindly placing their votes and trusting the machine without receiving any type of external verification or recount resource. This has generated much debate and several proposed solutions in the States where DRE voting machines have been integrated. One of these States is Nevada, which has taken the step to mandate the use of DRE voting machines in conjunction with Voter Verified Recorders (VVR), which output a human readable record of all of the ballots cast by the voters.
State of Nevada’s Secretary of State has chosen Sequoia Voting Systems as the supplier of the VVRs [3]. A VVR consists of two drum rollers with a continuous feed paper roll, a printer, and a clear window on the front of the sealed device which allows the verification of the printed record by the voter before leaving the voting booth. Additionally, the records produced by the VVR offer a means to perform a recount, if necessary. Events in which a recount would be required include a close election, software failure, hardware failure, and an internal or external audit. However, such a recount would require that each roll be counted by hand, which can prove to be a time consuming, expensive, and error-prone process.
In order to improve the recount process and verify the integrity of the electronic voting system, we have been presented with the opportunity to design an electronic ballot reader, which would read the printed record and tally the votes in order to verify the accuracy of the DRE/VVR record. With such a system, users would also be able to recall and view images of any ballots and records that the machine cannot verify or read, limiting the effects of OCR errors. The execution of this will require the use of an optical scanner, Optical Character Recognition software, tabulation software, configuration software and quality control software. Our preference is to use C/C++ and HTML, in conjunction with C/C++ libraries and GNU OCR software, on a Linux box in order to implement the necessary components. Since the VVR will be scanned and interpreted by OCR software, errors are a possibility [1]. This will require the tabulation software to perform statistical analysis on the results, which will give officials the opportunity to intervene.
The goal of this project is to provide a working prototype to demonstrate to voting officials that the only part of the voting process that is not computerized can feasibly be computerized, eliminating the human error factor inherent in counting votes by hand. In demonstrating this successfully, the system may have the opportunity of becoming an integral part of the voting system within the state of Nevada. It may also have the potential to be adopted statewide and nationwide in any county, state, or national election. Currently, there are several touch screen electronic voting systems in existence now, but there is no means to verify the system, which will make our solution the first of its kind.
In order to accomplish the successful specification and implementation of the system, Dr. Sergiu Dascalu and Mr. Lou Montulli will provide us with the necessary guidance and advisement. We shall seek advice from Dr. Dascalu with regards to the specification of the project and from Mr. Montulli with regards to the desired implementation of the system due to his active involvement in working to attain such a system. The format of the following sections is in accordance with UML standards [4].
This section specifies both functional and non-functional requirements for the Electronic Ballot Reader (EBR). The basic model is well understood, but other requirements may surface in later phases of the design process. All requirements are of priority level one unless specified.
2.1
Function Requirements
The following is a list of current functional requirements for the Electronic Ballot Reader:
R01 – The system shall provide a method for entering voting record separators.
R02 – The system shall provide a method for entering all Federal Offices on the ballot.
R03 – The system shall provide a method for entering all State Offices on the ballot.
R04 – The system shall provide a method for entering all Local Offices on the ballot.
R05 – The system shall provide a method for entering all candidates listed on the ballot for Federal Offices.
R06 – The system shall provide a method for entering all candidates listed on the ballot for State Offices.
R07 – The system shall provide a method for entering all candidates listed on the ballot for Local Offices.
R08 – The system shall provide a method for entering all State Propositions listed on the ballot, and the possible choices presented the voter.
R09 – The system shall provide a method for entering all Local Propositions listed on the ballot, and the possible choices presented the voter.
R10 – The system shall provide a method for the voting official to scan each VVR, and record the results on the system hard drive.
R11 – The system shall provide a method to read each scanned VVR and tabulate the results.
R12 – The system shall provide links to access the image and text files for each scanned ballot.
R13 – The system shall read one ballot at a time.
R14 – The system shall allow the correction of one ballot at a time.
R15 – The system shall provide a method for the voting official to certify the results once the verification process is complete.
R16 – The system shall provide a method producing a hardcopy of the certified results.
2.2
Non-Functional Requirements
T01 – The system’s target platform will be on Intel x86 computer running the Linux operating system.
T02 – The system will be written in C/C++.
T03 – The system interface will be written in HTML.
T05 – The system will use an external flatbed scanner to scan VVRs.
T06 – The system will use open source Linux based imaging scanning drivers to acquire scanned images.
T07 – The system will use open source Linux based optical character recognition (OCR) software to convert scanned images into text files.
T08 – The system will use custom scanning equipment to scan VVRs. Replaces T05. (Priority Two)
T09 – The system will contain embedded scanning software to automate the process of scanning VVRs. Replaces T06. (Priority Two)
T10 – The system will contain embedded OCR software to automate the process of converting scanned images into text files. Replaces T07. (Priority Two)
The EBR is defined by the functional specifications (Section 2) and can be understood by the use of Use Cases and Scenarios. The diagram in Figure 3.1 shows the entire functionality of the EBR, which is followed by description of each Use Case. Primary and secondary scenarios are provided for Use Cases ‘Enter Candidates’, ‘Feed VVR into Scanner’, and ‘Correct Systemic Anomalies’.
|
Figure 3.1 – System Environment (overview) |
|
Figure 3.1.1 – Configure Subsystem |
|
Figure 3.1.2 – Scan Subsystem |
|
Figure 3.1.2 – Certify Subsystem |
3.1
Use Case Description
The following are brief descriptions of each Use Case indicated in Figure 3.1.1, Figure 3.1.2, and Figure 3.1.3. Three detailed Use Cases are provided in Section 3.2.
UC01 – Enter Record Separator |
1) Enter the text on the VVR that indicates the beginning of a new voter record. 2) Specify line spacing between record separator and first line of record. 3) Enter the text on the VVR that indicates the end of current record. (Optional) |
UC02 – Enter Offices |
1) Enter all Federal Offices as they appear on the ballot. 2) Enter all State Offices as they appear on the ballot. 3) Enter all Local Offices as they appear on the ballot. |
UC03 – Enter Candidates |
1) Enter all candidates listed on the ballot for all Federal Offices entered in UC02. 2) Enter all candidates listed on the ballot for all State Offices entered in UC02. 3) Enter all candidates listed on the ballot for all Local Offices entered in UC02. 4) Verify any cross office/level duplicate entries. |
UC04 – Enter Propositions |
1) Enter all State Propositions placed before the voters. 2) Enter all Local Propositions placed before the voters. 3) Verify any cross level duplicate entries. |
UC05 – Enter Choices |
1) Enter choices for State Propositions as they appear on the ballot. 2) Enter choices for Local Propositions as they appear on the ballot. |
UC06 – Initiate Scan Sequence |
1. Connect interface cable to scanner. 2. Connect interface cable to computer. 3. Ensure power cord is plugged into power source. 4. Turn scanner on. |
UC07 – Feed VVR Into Scanner |
1) Place VVR sheet/roll on scanner. 2) Scan VVR as an image file to be stored on the local hard drive. 3) Send image file to OCR software to be converted into a text file that will be stored on the hard drive. 4) Repeat for each VVR sheet/roll. |
UC08 – Finish Scanning |
1. Ensure that all VVRs have been scanned. 2. Ensure that an image file exists on the computer for each VVR. 3. Ensure that a text file exists on the computer for each VVR. 4. Select ‘Scanning Complete’ option. |
UC09 – Correct Systemic Anomalies |
1) All possible systemic anomalies are displayed. 2) Select each anomaly and view associated image file. 3) Verify anomaly for correctness. 4) If correct certify anomaly as correct. Else assign ballot to proper candidate. |
UC10 – Certify Results |
1) Ensure that all corrections have been made (UC09). 2) Select ‘Certify’. 3) Enter identifying information for verifying voting official. 4) Print, sign, and submit report.
|
3.2
Selected Detailed Use Cases
3.2.1
Use Case Three (UC03)
Use Case: Enter Candidates |
ID: UC03 |
Actors: Voting Official |
Preconditions: |
Flow of events: 1. If “Federal Office” was selected from “Enter Offices” 1.1. For each federal office available 1.1.1. Enter the possible candidates 1.2. Voting Official confirms the “Federal Office” section 2. If “State Office” was selected from “Enter Offices” 2.1. For each state office available 2.1.1 Enter the possible candidates 2.2. Voting Official confirms the “State Office” section 3.1.1. If “Local Office” was selected from “Enter Offices” 3.1. For each local office available 3.1.1. Enter the possible candidates 3.2. Voting Official confirms the “Local Office” section 4. The system checks for candidates which appear in more than one office. 5. If candidate is entered for more than one office 5.1 The system prompts the Voting Official to correct the duplicate entry. |
Postconditions: 1. The Voting Official can enter ballot propositions. 2. The Voting Official can initiate the scan sequence. |
Alternative Flow 1: 1. At any time the
Voting Official can return to the “Enter Offices” use case. |
Postconditions: 1. The Voting
Official can then enter the names of the candidates for each office. |
Use Case: Enter
Candidates Primary Scenario |
ID: UC03 |
Actors: Voting Official |
Preconditions: 1. The “Enter
Offices” use case has been completed |
Primary scenario: |
Secondary Scenarios: 1. ReturnToEnterOffices |
Postconditions: |
Use Case: Enter
Candidates Secondary
Scenario: ReturnToEnterOffices |
ID: UC03 |
Actors: Voting Official |
Preconditions:
The “Enter Offices” use case has been completed |
Secondary scenario: |
Postconditions: 1. The voting official can then enter the names candidates for each office. |
3.2.2
Use Case Seven (UC07)
Use Case: Feed
VVR Into Scanner |
ID: UC07 |
Actors: Voting Official |
Preconditions: |
Flow of events: 1. The use case starts when the precondition is met. 2. The VVR is fed/placed into the scanner. 3. A scan is initiated by pressing the scan button. 4. Scan results are stored on the computer’s hard drive in a image format. 5. Image files are converted into text files. 6. Scanning is completed when the postconditions are met. |
Postconditions: 1. All Voter Verification Records have been scanned and converted to text files. |
Use Case: Feed
VVR Into Scanner Primary Scenario |
ID: UC07 |
Actors: Voting Official |
Preconditions: 1. Voting Official
has initiated the scan sequence. |
Primary scenario: |
Secondary Scenarios: 1. Scanning Failure |
Postconditions: 1. All Voter Verification Records have been scanned and converted to text files. |
Use case: Feed
VVR Into Scanner Secondary Scenario: Scanning Failure |
ID: UC07 |
Actors: Voting Official |
Preconditions:
A scanning error occurred. |
Secondary scenario: |
Postconditions: Scanning error has been resolved. |
3.2.2
Use Case Nine (UC09)
Use Case: Correct Systemic Anomalies |
ID: UC09 |
Actors: Voting Official |
Preconditions: |
Flow of events: 1. The use case starts when the above precondition is met. 2. The system displays the list of ballots containing anomalies. 3. For each ballot, the system provides: a. A text file link. b. An image file link. c. An inactive Correction selection. 4. The system provides a Submit and a Cancel selection. 5. For each ballot, the Voting Official makes the necessary corrections, a. If the Voting Official selects Correction, i. If Correction is inactive 1. The system displays a message informing the Voting Official that review of either the text file or the image file is required before a correction to the ballot can be made. ii. Else if Correction is active, 1. The system displays the corresponding candidates or answers for the category containing the anomaly in a secondary window. 2. The system provides a Submit selection. 3. The Voting Official makes the desired selection 4. The Voting Official selects Submit. b. If the Voting Official selects a ballot’s text file link, i. The system opens and displays the text file of the ballot. ii. If Correction is inactive, 1. The system activates the Correction selection. c. If the Voting Official selects a ballot’s image file link, i. The system opens and displays the image file of the ballot. ii. If Correction is inactive, 1. The system activates the Correction selection. 6. If the Voting Official selects Submit, a. The system updates the prior voting results to reflect the ballot corrections made. 7. Else if the Voting Official selects Cancel, a. The system nulls any corrections made and does not update prior voting results. 8. The system displays the voting results. |
Postconditions: 1. The voting results are displayed |
Use Case: Correct Systemic
Anomalies Primary Scenario |
ID: UC09 |
Actors: Voting Official |
Preconditions: 1. The Voting Official selects Correct Systemic Anomalies |
Primary scenario: 1. The Voting Official selects the text file link for the desired ballot. 2. The system opens and displays the text file for the selected ballot. 3. The system activates the Correction selection. 4. The Voting Official selects the image file link for the ballot. 5. The system opens and displays the image file for the selected ballot. 6. The Voting Official selects Correction. 7. The system displays the corresponding candidates or answers for the category containing the anomaly in a secondary window. 8. The Voting Official makes the desired selection. 9. The Voting Official selects Submit. 10. The Voting Official and the system execute the above steps for each ballot. 11. The Voting Official selects Submit. 12. The system updates the prior voting results to reflect the corrections made. 13. The system displays the updated voting results. |
Secondary Scenarios: 1. ViewListOnly 2. CorrectFirst 3. CancelCorrections 4. CorrectSomeBallots |
Postconditions: 1. The updated voting results are displayed. 2. The Correct Systemic Anomalies selection is removed. |
Use Case: Correct Systemic
Anomalies Secondary Scenario: ViewListOnly |
ID: UC09 |
Actors: Voting Official |
Preconditions: 1.
The Voting Official selects Correct Systemic
Anomalies |
Secondary scenario: |
Postconditions: 1. The initial voting results are displayed. 2. The View Anomalies selection is still available. |
Use Case: Correct Systemic
Anomalies Secondary Scenario: CorrectFirst |
ID: UC09 |
Actors: Voting Official |
Preconditions: |
Flow of events: 1. The Voting Official selects Correction. 2. The system displays a message informing the Voting Official that review of either the text file or the image file is required before a correction to the ballot can be made. 3. The Voting Official selects the text file link for the desired ballot. 4. The system opens and displays the text file for the selected ballot. 5. The system activates the Correction selection. 6. The Voting Official selects the image file link for the ballot. 7. The system opens and displays the image file for the selected ballot. 8. The Voting Official selects Correction. 9. The system displays the corresponding candidates or answers for the category containing the anomaly in a secondary window. 10. The Voting Official makes the desired selection. 11. The Voting Official selects Submit. 12. The Voting Official and the system execute steps 3 through 11 for each of the remaining ballots. 13. The Voting Official selects Submit. 14. The system updates the prior voting results to reflect the corrections made. 15. The system displays the updated voting results. |
Postconditions: 1. The updated voting results are displayed. 2. The Correct Systemic Anomalies selection is removed. |
Use Case: Correct Systemic
Anomalies Secondary Scenario: CancelCorrections |
ID: UC01/SC04 |
Actors: Voting Official |
Preconditions: 1.
The Voting Official selects Correct Systemic
Anomalies |
Secondary Scenarios: 1. The Voting Official selects the text file link for the desired ballot. 2. The system opens and displays the text file for the selected ballot. 3. The system activates the Correction selection. 4. The Voting Official selects the image file link for the ballot. 5. The system opens and displays the image file for the selected ballot. 6. The Voting Official selects Correction. 7. The system displays the corresponding candidates or answers for the category containing the anomaly in a secondary window. 8. The Voting Official makes the desired selection. 9. The Voting Official selects Submit. 10. The Voting Official and the system execute steps 3 through 11 for each of the remaining ballots. 11. The Voting Official selects Cancel. 12. The system nulls the ballot corrections made. 13. The system displays the initial voting results. |
Postconditions: 1. The initial voting results are displayed. 2. The Correct Systemic Anomalies selection is still available. |
Use Case: Correct Systemic
Anomalies Secondary Scenario: CorrectSomeBallots |
ID: UC09 |
Actors: Voting Official |
Preconditions: 1.
The Voting Official selects Correct Systemic
Anomalies |
Secondary scenario: 1. The Voting Official selects the text file link for the desired ballot. 2. The system opens and displays the text file for the selected ballot. 3. The system activates the Correction selection. 4. The Voting Official selects the image file link for the ballot. 5. The system opens and displays the image file for the selected ballot. 6. The Voting Official selects Correction. 7. The system displays the corresponding candidates or answers for the category containing the anomaly in a secondary window. 8. The Voting Official makes the desired selection. 9. The Voting Official selects Submit. 10. The Voting Official and the system execute steps 3 through 11 for some of the remaining ballots. 11. The Voting Official selects Submit. 12. The system updates the prior voting results to reflect the corrections made to selected ballots. 13. The system displays the updated voting results. |
Postconditions: 1. The updated voting results are displayed. 2. The Correct Systemic Anomalies selection is still available. |
Require-ments |
Use Cases |
|||||||||
01 |
02 |
03 |
04 |
05 |
06 |
07 |
08 |
09 |
10 |
|
R01 |
X |
|
|
|
|
|
|
|
|
|
R02 |
|
X |
|
|
|
|
|
|
|
|
R03 |
|
X |
|
|
|
|
|
|
|
|
R04 |
|
X |
|
|
|
|
|
|
|
|
R05 |
|
|
X |
|
|
|
|
|
|
|
R06 |
|
|
X |
|
|
|
|
|
|
|
R07 |
|
|
X |
|
|
|
|
|
|
|
R08 |
|
|
|
X |
X |
|
|
|
|
|
R09 |
|
|
|
X |
X |
|
|
|
|
|
R10 |
|
|
|
|
|
X |
X |
X |
|
|
R11 |
|
|
|
|
|
X |
X |
X |
|
|
R12 |
|
|
|
|
|
|
|
|
X |
|
R13 |
|
|
|
|
|
|
|
|
X |
|
R14 |
|
|
|
|
|
|
|
|
X |
|
R15 |
|
|
|
|
|
|
|
|
|
X |
R16 |
|
|
|
|
|
|
|
|
|
X |
The user interface is will be design entirely in HTML in order to allow other voting officials to monitor the electronic ballot reading process. Two sample screen shots are provided bellow. Figure 5.1 shows the interface for entering specific candidates for the President of the United States. Figure 5.2 for local offices, in this case the City of Reno, and Washoe County offices. These screen shots are just samples and will change once we enter the design phase of the project. The one major change will be the addition of embedded scripts to control the behavior of the browser.
|
Figure 5.1 |
|
Figure 5.2 |
General specification decisions such as selection of Use Cases, and which optional reports were implemented, where made in committee. Specific implementations were assigned as follows:
Rosa Arias: Detailed Use Case Nine (UC09); Requirement specification.
Chad Feller: Detailed Use Case Three (UC03); User interface screen shots.
Walter Smith: Detailed Use Case Seven (UC07); Publishing this document.
Digital Recording Electronic (DRE) – A digital electronic device used to record a voter’s selection of candidates and proposition choices during an election. Is intended to replace the traditional paper ballot. When networked together with other DREs in the same voting place a accurate tally of votes can be tabulated.
Flatbed Scanner – Hardware device used to convert a paper based record into an image that scan be stored on a computer. Requires that each record be on a sheet of paper, as opposed to a sheet fed scanner which can scan a single sheet of paper or a entire roll of paper without intervention.
HTML – Stands for Hypertext Markup Language. Used by web developers to design webpages for use over the internet. The user interface will be designed using HTML to allow other voting officials to monitor the process counting and certifying the VVR.
HTTP – Stands for Hypertext Transport Protocol. Protocol used to distribute HTML documents between providers and users. Web servers and browsers use this protocol communicate. The software in this projected will be implemented as a HTTP server to provide the user interface.
Optical Character Recognition (OCR) Software – A collection of software utilities that can take an image file as input and output a text file. More advance versions can convert the text in an image to popular word processing formats. For this project only a simple text format is needed.
Voting Official – An official elected too, or appointed by elected officials, or monitor all election processes within a voting district. The voting official is the central actor of the process used by this project.
Voter Verification Record (VVR) – A printable record of each voter’s choices that is kept within a DRE to provide a paper trail for voting officials. This is the record that will be used in this project.
8
References
[1] A. Corrado and C. M. Firestone Editors, Elections in Cyberspace: Toward a New Era in American Politics, The Aspen Institute, 1996. Provides background on the subject of using computer technology to automate the voting process. Several scenarios are presented that outline the benefits and potential problems that may occur. (Domain Book)
[2] Sequoia AVC Edge, Sequoia Voting Systems, Oakland, CA, 2004. Gives a description of the electronic hardware that will be used in Nevada’s 2004 general election. Also provides an online demonstration on how this product is to be used. http://www.sequoiavote.com/bAVCEdge.php
[3] Voter Verifiable Paper Record Printer, Sequoia Voting Systems, Oakland, CA, 2004. This article describes the how the VVR is to be produced. Because this product is currently in the testing phase no example output is provided. http://www.sequiavote/mediadetail.php?id=74
[4] J. Arlow and I. Neustadt, UML and the Unified Process, Addison-Wesley, 2002. Provides examples and detailed description on UML usage and the design process.