USE CASES FOR THE ELECTION SYSTEM

We consider 5 issues into which we can separate the situations that we have to handle:

Preprocess.

Election.

Postprocess.

System hierarchy.

Interaction with voters.

System hierarchy:

We think of ourselves as a company that develops software for election systems. Our customers can be administration offices at any level. They’ll set up elections that can occur independently, or they can be intercommunicating. At every election there will be a master system that can have several other systems helping it to handle the election.

We make the following distinctions:

System: Election software bought by somebody and running on some (maybe) distributed platform, which controls an election.

Election: each system has 1 election at every time.

Subelection: if a system is handling several elections, we call each of them ‘subelection’.

Questions: Each subelection will have a set of questions to be answered. Any voting situation can be described by a set of questions. For example, we can think of actually making questions in a referendum, or we can think that selecting a candidate (party) is answering to the question "Do you want this candidate?"

Answers: Every question can have multiple answers, and the user has to pick one.

The voter can vote in any subelection that he is allowed to. Besides, the most general way of defining the voting procedure might be answering up to a certain number of questions from the complete set. This covers all the practical cases that we could come up with.

Preprocess:

We have to start an election initializing many things.

First the administration system that owns the system calls for the election (maybe creates an object) and sets the parameters.

We need a database with info about the potential voters. This might be a census that is stored somewhere. For local elections, we may build the database using info from state level, etc.

We don’t consider a registration operation. Potential voters are already registered since they are in the census and they data are checked to see if they are allowed to vote. At some time in their life they must have been queried about their info, and it can be changed dynamically.

When the election is called, the administration starts a time when people can check if their situation is correct. They access the system following some authentication process, and if something is wrong, they report it to the system administrator so that it can fix it.

Authentication: We think that it deserves a separate description.

Assume that we have an authentication process with some id for every person and a way of proving that he’s that person (password, fingertip recognition, etc.).

The ‘ID + password’ method seems to have some problems: It would allow people to vote in the name of other people. If somebody tells other person his password and ID, that person can vote. However, physical recognition methods prevent people from doing this. On the other hand, they might discourage some people from voting (??).

Anyway, at some time there must be a personal interaction between the citizens and the administrator to get ids, passwords, or any other authentication data.

Database: The database should be constructed in such a way that somebody can access his/her info based on the ID. Everybody will have all the data required for the election stored in his personal account. These data can be: name, age, home, country of citizenship, etc. Eventually, all the data required to identify that person and to decide if he/she is eligible for voting or not.

We thought that people may not be willing to share some of this information, but since the institution that handles it is the public administration, which already knows that info, we think that there shouldn’t be problems.

Administrator labor during the election:

The system administrator has to set off the election and control the end time.

We have considered the possibility of counting the votes on the fly. There are different pros and cons for this.

The most important advantage is that the results are known faster. However, there are different disadvantages:

Another element that is up to us is if we want to keep the votes. Moreover, do we want to keep the link between a vote and the voter that emitted it? Since voting must be secret, it’s convenient not to keep this link, but it has to be kept if voters are allowed to change their mind. Regarding keeping the results, it seems convenient to keep them, just in case we need a recount, etc.

It’s not clear how the administrator should act if the system breaks down.

Do we want to keep records of all the accesses to the system, the interactions, etc? This might be desirable if it allows us to solve conflicts, etc. However, if hackers can modify data, they can modify these records too, and we may not want to store them.

Interaction with the voters:

The user does the following:

Postprocess:

The actions that we should are:

There are important questions like when to count, when to disclose results, when to end the election... If we have a single election, the easiest thing is having a single start and end time everywhere. We don’t have problems derived from current election systems: there are no election officers that need to be awake all the time; if the election take place at a place with different hour uses, the system can start early for one and end late for the other, voters can vote whenever they want.

There is something that we should avoid. Results shouldn’t be revealed anywhere if the election has not ended somewhere, as long as those results can influence the ongoing election. Local elections can be counted as soon as they end at each place, because they don’t have any influence in other places.

If there are local elections for many places taking place simultaneously, the election time will be the one of the place that every citizen is voting for, no matter where he is. If he is voting for Chapel Hill’s major from Australia, the available election time will be that of Chapel Hill.