Electronic Ballot Reader

 

 

 

Rosa Arias, Chad Feller, Walter Smith

 

27 February 2004

 


TABLE OF CONTENTS

 

1  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      3

 

2  Requirements Specification

          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

 

4  Requirement Traceability Matrix . . . . . . . . . . . . . . . . . . . . . . . . . 19

 

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].

 

 

2 Requirements Specification

 

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.

 

T04 – The system will implement a custom HTTP server to respond to commands from the user interface.

 

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)

 

 

3 Use Case Modeling

 

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

 

This section provides detailed descriptions of three use cases and their associated primary scenario and secondary scenarios.

 

3.2.1 Use Case Three (UC03)

 

Use Case: Enter Candidates

ID:  UC03

Actors:

Voting Official

Preconditions:

1.  The “Enter Offices” use case has been completed.

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:

1. The use case begins after the Voting Official has completed the “Enter Offices” use

    case.

2. “Federal Office” was selected from “Enter Offices”

3. The system retrieves the list of federal offices available.

4. For each federal office available from the retrieved list

     4.1. The system prompts the Voting Official to enter all of the candidates available

             for this office.

5. The system stores each candidates name, checking for duplicates

6. The Voting Official confirms the “Federal Office” section.

7. “State Office” was selected from “Enter Offices”

8. The system retrieves the list of state offices available.

10. For each state office available from the retrieved list

      10.1. The system prompts the Voting Official to enter all of the candidates

               available for this office.

11. The system stores each candidates name, checking for duplicates.

12. The Voting Official confirms the “State office” section.

13. “Local office” was selected from “Enter Offices”

14. The system retrieves the list of local offices available.

15. For each local office available from the retrieved list

      15.1. The system prompts the Voting Official to enter all of the candidates

               available for this office.

18. The system stores each candidates name, checking for duplicates.

19. The Voting Official confirms the “Local Office” section.

20. The system checks to see that a candidate was not entered for more than one office.

21. The system finds duplicate entries.

22. The system prompts the Voting Official to correct the duplicate entries.

23. The Voting Official corrects the duplicate entries.

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:

1. This use case happens as result of  “Alternative Flow 1”.

2. At any time the Voting Official can return to “Enter Offices” to edit the selected

    offices.

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:

1.  Voting Official has initiated the scan sequence.

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:

1. The Voting Official places a page of the VVR into the scanner.

2. The Voting Official presses the ‘Scan’ button on the scanner.

3. The scanning software will create an image of the VVR page and create an image file on the hard drive.

4. The Voting Official will start the Optical Character Recognition software, which will convert each of the scanned images into text files also stored on the computer’s hard drive.

5. The Voting Official indicates to the system that all VVRs have been scanned, and converted into text files without error.

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:

1. The Voting Official is notified by the scanner, or computer software that a scanning error has occurred.

2. The Voting Official checks both ends of the interface cable to ensure that it is fully seated at both ends.

3. The Voting Official checks both ends of the power cable to ensure that it is fully seated at both ends.

4. The Voting Official either:

    a) Continues if error has been resolved

    b) Contacts a technician to resolve the problem.

         1) If problem can be resolved then the Voting Official continues the process.

         2) If problem cannot be resolved then the scanner must be replaced, and the entire system must be restarted.

Postconditions: Scanning error has been resolved.

 

3.2.2 Use Case Nine (UC09)

 

Use Case:  Correct Systemic Anomalies

ID:  UC09

Actors: Voting Official

Preconditions:

1.      The Voting Official selects Correct Systemic Anomalies

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:

1.      The Voting Official selects Cancel.

2.      The system makes no updates.

3.      The system displays the initial voting results.

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:

1.      The Voting Official selects Correct Systemic Anomalies

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.

 

 

 

 

 

4  Requirement Traceability Matrix

 

 

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

 

 

 

5  User Interface

 

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

 

 

6 Team Member Contributions

 

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.


 

7 Glossary of Terms

 

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.