22-08-2014, 10:30 AM
Functional Requirements for a Secure Electronic Voting System Seminar Report
[attachment=66872]
INTRODUCTION
The advent of information society has enabled people to perform most of
their activities in a direct, electronically automated, and efficient way. To
keep up with the need to provide citizens with the ability to participate and
benefit from services over the Internet, as well as to reduce the cost and
bureaucracy of public administration, contemporary states are striving to
transfer an ever-increasing number of their activities to the new medium.
Electronic voting has been considered to be an efficient and cost effective
alternative/complement of the classic voting procedure, as well as a way to
attract specific groups of people, like young electors [1], to participate.
However, in parallel to their initial interest, state authorities are concerned,
and need justification, on the compliance of electronic voting systems with
the current legal framework. Along these lines, it is rather usual to identify
the “requirements” of an electronic voting system merely as guidelines to
conform to the legislation governing general elections [2].
On the other hand, information system developers approach electronic
voting with an eye towards identifying the fundamental problems associated
with the adequate level of security (anonymity, authentication, data security,
tractability, etc). It seems though that the severity of these problems has
attracted most of the attention, since the majority of the literature
concentrates on the ability of an electronic voting system to handle them [3,
4]1
. In [6], for example, this distinction is apparent since requirements are
identified as legal, technical, and user oriented - the latter in the form of
conditions the system should
METHODOLOGY USED
In this paper, requirements elicitation has been based on the Rational
Unified Process [7, 8]. The Rational Unified Process is the synthesis of
various software development processes [7]; one of its most important
characteristics is that it is use-case driven. Use cases as a requirements
capturing method were first introduced by Jacobson [9] and despite their
somewhat informal nature have become a popular tool [10]. Each use case
mainly refers to a functional requirement [11] of the system. Non-functional
requirements specific to a use case may become part of its description, whilst
system-wide non-functional requirements are usually specified as
supplementary specifications [12].
A fundamental activity of the requirements elicitation process is the
development of the domain model demonstrating current workers and
processes. Initially, a business use case model is developed demonstrating
current processes or what the business does. Further analysis leads to the
business object model revealing how business processes are performed. In
that way, system designers familiarise themselves with the problem at hand,
while at the same time they reach a good level of understanding regarding
how users perceive the system to be developed. In addition, a mutual
apprehension of objections, suggestions and proposed solutions is achieved,
facilitating productive communication. A generic voting model is described
in section 2 of this paper. We have merged the business use cases and the
business object models, in order to keep its size acceptable, without limiting
its value
VOTING MODEL
Although the process of voting may be generally visualized in the context
of an electoral procedure, e.g. general elections, we have identified four
different areas where voting plays a central role:
1. General Elections.
2. Internal Election Procedures (e.g. trade unions' elections, etc.).
3. Decision-Making (e.g. Referenda, etc.).
4. Polls of indicative or advisory nature.
The above procedures are organised and conducted in a similar way,
although - normally - different legal/regulatory frameworks govern them.
We can nevertheless argue that general elections, which is the broadest and
E-VOTING FUNCTIONAL REQUIREMENTS
As we have stated before, the traditional model provided the basis for the
e-vote system requirements specification. In accordance with the business
use cases of the model we have identified the following system use cases:
Authorize Actor: This use case is the starting point for any interaction
with the information system. It is a general use case specialized for
organizers, i.e. “Authorise organiser” and users i.e. “Authorise user
Manage Election Units
Election unit is the system counterpart of the
“election centre”. In the conceptual model the election centre is central to the
election procedure, as it is the fundamental tallying point. Besides, in case
electronic voting is performed in a controlled environment, with machines
provided by the state, all votes cast from a certain “electronic” election point
should be able to be traced back to that point
CONCLUSIONS AND FURTHER WORK
In this paper we have identified the need for systematically producing a
complete set of requirements specification for electronic voting systems that
unifies the requirements imposed by the existing European legal framework,
the functionality reflected by the conventional voting procedures, and the
required security attributes that the system should exhibit.We have applied a software engineering methodology for elicitating user
requirements specification in a widely accepted format. This has been
accomplished through a set of use cases, along with supplementary
specifications. We have, thus, conceptualised an e-voting system in its
entity, in a way that confines the number of possible subsequent designs, yet
does not dictate a particular one.
This requirements specification is the outcome of the first “iteration” of
the requirements elicitation process. We are currently validating and
enhancing these requirements focusing, also, on non-functional ones and
expect to incorporate the outcome of these activities in the system design
and development phases.
[attachment=66872]
INTRODUCTION
The advent of information society has enabled people to perform most of
their activities in a direct, electronically automated, and efficient way. To
keep up with the need to provide citizens with the ability to participate and
benefit from services over the Internet, as well as to reduce the cost and
bureaucracy of public administration, contemporary states are striving to
transfer an ever-increasing number of their activities to the new medium.
Electronic voting has been considered to be an efficient and cost effective
alternative/complement of the classic voting procedure, as well as a way to
attract specific groups of people, like young electors [1], to participate.
However, in parallel to their initial interest, state authorities are concerned,
and need justification, on the compliance of electronic voting systems with
the current legal framework. Along these lines, it is rather usual to identify
the “requirements” of an electronic voting system merely as guidelines to
conform to the legislation governing general elections [2].
On the other hand, information system developers approach electronic
voting with an eye towards identifying the fundamental problems associated
with the adequate level of security (anonymity, authentication, data security,
tractability, etc). It seems though that the severity of these problems has
attracted most of the attention, since the majority of the literature
concentrates on the ability of an electronic voting system to handle them [3,
4]1
. In [6], for example, this distinction is apparent since requirements are
identified as legal, technical, and user oriented - the latter in the form of
conditions the system should
METHODOLOGY USED
In this paper, requirements elicitation has been based on the Rational
Unified Process [7, 8]. The Rational Unified Process is the synthesis of
various software development processes [7]; one of its most important
characteristics is that it is use-case driven. Use cases as a requirements
capturing method were first introduced by Jacobson [9] and despite their
somewhat informal nature have become a popular tool [10]. Each use case
mainly refers to a functional requirement [11] of the system. Non-functional
requirements specific to a use case may become part of its description, whilst
system-wide non-functional requirements are usually specified as
supplementary specifications [12].
A fundamental activity of the requirements elicitation process is the
development of the domain model demonstrating current workers and
processes. Initially, a business use case model is developed demonstrating
current processes or what the business does. Further analysis leads to the
business object model revealing how business processes are performed. In
that way, system designers familiarise themselves with the problem at hand,
while at the same time they reach a good level of understanding regarding
how users perceive the system to be developed. In addition, a mutual
apprehension of objections, suggestions and proposed solutions is achieved,
facilitating productive communication. A generic voting model is described
in section 2 of this paper. We have merged the business use cases and the
business object models, in order to keep its size acceptable, without limiting
its value
VOTING MODEL
Although the process of voting may be generally visualized in the context
of an electoral procedure, e.g. general elections, we have identified four
different areas where voting plays a central role:
1. General Elections.
2. Internal Election Procedures (e.g. trade unions' elections, etc.).
3. Decision-Making (e.g. Referenda, etc.).
4. Polls of indicative or advisory nature.
The above procedures are organised and conducted in a similar way,
although - normally - different legal/regulatory frameworks govern them.
We can nevertheless argue that general elections, which is the broadest and
E-VOTING FUNCTIONAL REQUIREMENTS
As we have stated before, the traditional model provided the basis for the
e-vote system requirements specification. In accordance with the business
use cases of the model we have identified the following system use cases:
Authorize Actor: This use case is the starting point for any interaction
with the information system. It is a general use case specialized for
organizers, i.e. “Authorise organiser” and users i.e. “Authorise user
Manage Election Units
Election unit is the system counterpart of the
“election centre”. In the conceptual model the election centre is central to the
election procedure, as it is the fundamental tallying point. Besides, in case
electronic voting is performed in a controlled environment, with machines
provided by the state, all votes cast from a certain “electronic” election point
should be able to be traced back to that point
CONCLUSIONS AND FURTHER WORK
In this paper we have identified the need for systematically producing a
complete set of requirements specification for electronic voting systems that
unifies the requirements imposed by the existing European legal framework,
the functionality reflected by the conventional voting procedures, and the
required security attributes that the system should exhibit.We have applied a software engineering methodology for elicitating user
requirements specification in a widely accepted format. This has been
accomplished through a set of use cases, along with supplementary
specifications. We have, thus, conceptualised an e-voting system in its
entity, in a way that confines the number of possible subsequent designs, yet
does not dictate a particular one.
This requirements specification is the outcome of the first “iteration” of
the requirements elicitation process. We are currently validating and
enhancing these requirements focusing, also, on non-functional ones and
expect to incorporate the outcome of these activities in the system design
and development phases.