Re: Specifications

From: Ken Pugh <kpughmisc_at_pughkilleen_dot_com>
Date: Tue Dec 14 2004 - 22:33:05 CST

Ed, At 10:52 PM 12/13/2004, you wrote:

>Ken Pugh wrote:

>>I guess I'm trying to specify the system from the user-centric
>>perspective (sort of like use cases, if you're familiar with them).
>No, could you please explain.

A use case specifies a user's interaction with a computer system. It is
stated in technology-independent terms. It does not specify a particular
implementation, rather what that implementation has to do. There are
various levels of use cases, some of which specify more technology
dependent issues. The use cases can then be used to determine what
features are needed in a system. The following is an informal use case.

For example,

User-casts-ballot Use Case

1.) The user starts the ballot by using a precinct identifying device.

2.) The system responds with a page with one (or more) races

3.) The user selects the candidates they wish to vote for using a pointing
device and then indicates to proceed to the next page.

4.) The system responds with the next page of races. After the first page,
the user also has the option to go back to the previous page.

5.) After the final page, the system responds by displaying all races with
the user's selections.

6.) The user may go back to the previous page (#3). If the user confirms
the selections, the system prints out a page with the user 's selections

7.) The user reviews the printed page. If the user is satisfied, the user
deposits the printed page in a locked box. If the user is not satisfied,
then ......

Note that the precinct identifying device could be a smart card, dumb card,
piece of paper, etc.; The pointing device could be touch screen, a mouse,
a trackball, etc.

>>At this level, the
>>features required of an operating system or a particular language are
>>important, but not the actual O/S or language.
>Yep, I was just trying to codify what people were saying at the time. One
>of the biggest headaches of this sort of effort is the constant
>reinventing of the wheel.
>>Results may be sent via Access database format, comma-delimited
>>files, XML, or some standard format.
>Results from what? The polling place level canvassing system? I think we
>were planning to hand carry these to what we've generically called,
>"Election Central" typically, the County Registrar's office. The 'we'
>would consist of one member of each party to keep an eye on the other
>one(s). I guess we might have to use a van in San Francisco.

Are the results printed or in electronic mode? On the level that I'm
trying to aim for with these specifications, then the statement would be:

"The precinct level results must be transported by other than electronic
means to the election district tabulation office."

If electronic transmission was allowed, the actual form and means should
not be stated at this level, but rather the features that form provides.

>They could be sent via ftp,
>>http POST, email or a custom protocol.
> From where to where? From election central to the Secretary of State
> might be acceptable but from anywhere else to anywhere else, the design
> is network phobic for security reasons.

That's perfectly reasonable. So the specification should read as above.

>>What is important on the level I'm trying to focus on is that they be
>>printed out prior to connecting to the communication system so that
>>copies be cross-signed and distributed to a number of poll workers.
>Multiple copies, cross signing? While I can imagine what you might mean,
>why not make it easy for me. I'm just a middle aged bureacrat after all.

Regardless of whether the results were transmitted by manual means or
electronic means, there should be a printout of the results at the precinct
level. A copy of the results should be distributed to poll workers who
represent multiple candidates (interested parties).

If the poll workers sign each copy (to represent that their copy is an
exact duplicate of the other copy), then there should be no argument that
the results are exactly what was reported by the precinct tabulation

This feature was suggested by one of the websites that I visited.

>>There are certain features that would be necessary from a security
>>aspect that are not readily apparent to the voter or poll worker. These
>>might include features as:
>>1.) All ballots will be stored in two separate physical types of
>>storage (for backup).
>The idea had been to not only print the ballot but also to write them to a
>US B memory stick and to the program/ballot source CD. These were
>intended to be the backups.

That's a conforming implementation of the specification. I don't want to
draw the specification so tightly as to rule out other implementations, if
developers find other ways to meet it.

>>2.) There will be no accessible input or outputs to/from the unit
>>other than the printer connection, the monitor, and the mouse.
>Why a mouse with a touch screen?

I stated it too specific (in violation of my own guidelines !!). I should
have said pointing device.

>>3.) There will be an input/output device that is accessible only by
>>physical key. This device will be used to import/export data from the
>>computer via a secure mechanism.
>see item 1. Also, we had in mind put the CPU in a locked basket under the

Another conforming implementation.

>>4.) The communications protocol needs to prevent non-authorized
>>machines from transmitting data.
>See my discussion about being network phobic.

This should be applicable at any level that uses electronic communication.

>Thanks, Ed Kennedy
>>At 11:34 AM 12/13/2004, you wrote:
>>>Hello Ken:
>>>& is the link to
>>>some previous work that's been done on specifications. There are
>>>also other items that are like speicifications in the wiki. Perhaps
>>>you could try and incorporate these? Admittedly, not all of them hang
>>>Thanks, Ed Kennedy
>>>Ken Pugh <> wrote:
>>>Based on Ed Kennedy's stepping stone, here are some suggested
>>>features/specifications for the system. These are user-related
>>>features. They do not include security-related aspects.
>>>* Voting machine level
>>>a.) Uses or produces paper ballots.
>>>b.) Votes should be electronically tabulated during normal voting
>>>times or shortly thereafter
>>>c.) Detects invalid ballots (over-votes or illegible ballots)
>>>d.) Provide for sight-impaired voters a means of voting using audio.
>>>e.) (Optional) Detects under-votes and provides for correction
>>>f.) (Optional) Should permit voting even in the event of power or
>>>equipment failure
>>>g.) (Optional) Works the same for absentee ballots as for regular
>>>ballots. On the precinct level
>>>a.) Provides for paper vote totals at the precinct level
>>>b.) Precinct totals should be postable to the web for voter review.
>>>c.) Tied back to the voter check-in procedure to insure that the vote
>>>totals agree with the check-in. In the event of discrepancies, the
>>>totals must be reconciled.
>>>* Vote tabulation
>>>a.) Vote tabulation system should have checks to insure that all
>>>precincts have reported and that the precinct vote totals are
>>>reasonable in regards to voter registration and past history.
>>>b.) Numbers for voter-check-in and vote-totals are entered by
>>>separate processes. Numbers cannot be manually manipulated.
>>>>OVC discuss mailing lists
>>>>Send requests to subscribe or unsubscribe to
>>>OVC discuss mailing lists
>>>Send requests to subscribe or unsubscribe to
>>> --
>>>10777 Bendigo Cove
>>>San Diego, CA 92126-2510
>>>"We mus! t all cultivate our gardens." Candide-Voltaire
>>>OVC discuss mailing lists
>>>Send requests to subscribe or unsubscribe to
>>OVC discuss mailing lists
>>Send requests to subscribe or unsubscribe to
>OVC discuss mailing lists
>Send requests to subscribe or unsubscribe to

OVC discuss mailing lists
Send requests to subscribe or unsubscribe to
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Fri Dec 31 23:17:14 2004

This archive was generated by hypermail 2.1.8 : Fri Dec 31 2004 - 23:17:22 CST