University of Zimbabwe

Computer Science Department

E-VOTING SYSTEM
CHAPTER ONE
1. Introduction
1.1 Background
The project "E-Voting Software" aims at making the voting process easy in
cooperative societies. Presently voting is performed using ballot paper and
the counting is done manually, hence it consumes a lot of time. There can
be possibility of invalid votes. All these makes election a tedious task. In
our proposed system voting and counting is done with the help of
computer. It saves time, avoid error in counting and there will be no
invalid votes. It makes the election process easy
1.2 Statement of Problem or Nature of the Research Problem
Due to the continuous increase in population, the number of people taking part in the
voting exercise is increasing. The time taken to save these numbers and publish the results
has become a serious problem to the voting committee. This system is mainly being
designed in order to mainly make the voting process faster, easier and more accurate by
replacing human input with computer input.
1.3 Previous and Current Work, Methods and Procedures
Previously voting was done through the use of ballot boxes and ballot papers where
voters would actually write on the ballot paper indicating their candidate choice for a
certain position. This was then followed by physical counting and then publication of the
results. This process has a lot of drawbacks because the process is slow and there is a high
probability of human error. In order to counter this problem human input should be
replaced with computer input as there will no longer be human error and the speed of the
process will increase. An algorithm will be design that will do all the voting processes
that is from registration of voters, actual voting process, counting of results and then
publication of results.
1.4 Project Description/ Novel Characteristics of the Research

E-Voting system is a system that is designed to do all the processes of voting without
human interruption. The system will do the registration of voters and keep the records in a
database, control all the actual voting and then it will count and publish results. The only
human effort that is going to be seen is that of the administration who will be assisting
voters who will not be understanding how this new voting technology works and
changing the mode of the system from registration, voting, counting and then publication
of results.
1.5 Research Purpose/ Research Objectives/ Aims
We are to design a voting system that:
ensure quick and precise biometric voting identification
provide a simple and user-friendly interface for registering and identifying voters
prevent duplicate registers
is easily scalable
provide a clear and accessible audit trail
facilitate interoperability between agencies for database consolidation and
maintenance
1.6 Justification of Project/ Rationale/ Significance of project
The main objective of this voting system is to allow voters to exercise their right to
express their choices regarding specific issues, pieces of legislation, citizen initiatives ,
constitutional amendments, recalls and to choose their government and political
representatives. Technology is being used more and more as a tool to assist voters to cast
their votes. This is all to increase confidence in the users that everything in the voting
process is being done accurately and fairly.
1.7 Scope of the Study
This section specifies the system boundary that is it clearly spells out what is part of the
system and what is not part of the system.
1.8 Organisation of the project/ Summary / Presentation of Research
This section gives an overview of the whole project that is what is going to be covered in
each of the foregoing chapters.

CHAPTER TWO
2.

System Specification

2.1. Introduction
Give a brief introduction about what this chapter covers.
2.2.

System Functional Specification or Problem Definition

2.1.1

Functional Requirements
To count the total number of votes.
To calculate the percentage of total votes.
To calculate votes for each candidate.
To calculate percentage of votes for each candidate.
To check for duplication.
To find the winning persons in each section.
All the process above mentioned should be done fast

2.1.2

Non-Functional Requirements

System requirements
Hardware Requirements:

System

: Pentium IV 2.4 GHz.

Hard Disk

Floppy Drive : 1.44 Mb.

Monitor

: 15 VGA Colour.

Mouse

: Logitech.

Ram

: 512 Mb.

: 40 GB.

Software Requirements:

Operating system : - Windows XP.

Coding Language

: PHP

Data Base

: WAMPSERVER 2.5

2.1.3

System Evolution

The software should allow voters to log in to the system using their
usernames and passwords which they create during registration. Vote
transfer is dependent on access to fast and reliable servers, along with
constant access to the internet for students throughout the election.
Storage of the election data depends on access to a large enough
databases to hold all of the vote information. The assistance of Disability
Services is depended on for helping stuff whose disabilities hinder their
ability to cast their votes successfully and confidently. The voting officials

is depended on to provide information on the nuances of the election. The

officials are assumed to continue to be interested in the development of
the system and to be present throughout its implementation in order to
insure that their standards are being met. The security of the system as a
whole depends on reliable co-workers. Those overseeing the main
terminal and the paper trail will need to protect the election information.
Other people who have access to security information are assumed to be
trustworthy enough not to leak information to possible attackers.
2.1.4

System Scope

This stage involves establishing the system boundary. A system boundary depicts the parts of
the original requirements that are to be computerised. The developer must realise that that the
boundary may or not may enclose all requirements. When setting up a system boundary the
developer must consider among other things, the available resources, user requirements and
other limitations in implementing the system. Further this section must give a description of
system components and the system environment
2.1.5

Prototyping

Developers may use this technique if they want to validate the requirements. Prototyping
involves developing a quick and dirty but still convincing model of the final system. The
developer must articulate the goals of prototyping, functions prototyped and results of the
prototyping process.
2.1.6

User Interface Design

Give a detailed description of the system user interface including diagrams of all the ``work''
windows (or screens or panes), a table of operations for each work window, and precise
descriptions of each operation that the user would regard as unfamiliar. A work window is
one that contains data the user is editing, browsing or viewing. This section is required for all
programs that engage the user interactively.
2.1.7

Other User Inputs

Give a precise description of the other inputs to the system including source (human or
storage) syntax (format) and semantics (meaning). Give examples. This section is required
for all programs that obtain input from their environment non interactively.
2.1.8

Other User Outputs

Give a precise description of the other outputs of the system including syntax and semantics.
Correlate the outputs with the inputs and the functions performed. Give examples. This
section is required for all programs that obtain input from their environment non interactively.
2.1.9

System Data Files

Give a precise description of the data files created or maintained by the system. Thus, for
example, you would include files in a database and you would exclude executable files and
text files.

2.1.10 User Interface Specification

Interface Metaphor Model
User Screens/Dialog
Report Formats/Sample Data
On-line Help Material
Error Conditions and System Messages
Control Functions
2.3.

Feasibility Study

The feasibility of the project is analysed in this phase and

business proposal is put forth with a very general plan for the
project and some cost estimates. During system analysis the
feasibility study of the proposed system is to be carried out.
This is to ensure that the proposed system is not a burden to
the company. For feasibility analysis, some understanding of
the major requirements for the system is essential.

Three key considerations involved in the feasibility analysis are

ECONOMICAL FEASIBILITY
TECHNICAL FEASIBILITY
SOCIAL FEASIBILITY
2.3.1

Economic feasibility

This study is carried out to check the economic impact that the
system will have on the organization. The amount of fund that
the company can pour into the research and development of
the system is limited. The expenditures must be justified. Thus
the developed system as well within the budget and this was
achieved because most of the technologies used are freely
available. Only the customized products had to be purchased.
2.3.2

Technical Feasibility

This study is carried out to check the technical feasibility, that

is, the technical requirements of the system. Any system

developed must not have a high demand on the available

technical resources. This will lead to high demands on the
available technical resources. This will lead to high demands
being placed on the client. The developed system must have a
modest requirement, as only minimal or null changes are
required for implementing this system.
2.3.3. Social Feasibility

The aspect of study is to check the level of acceptance of the

system by the user. This includes the process of training the
user to use the system efficiently. The user must not feel
threatened by the system, instead must accept it as a
necessity. The level of acceptance by the users solely depends
on the methods that are employed to educate the user about
the system and to make him familiar with it. His level of
confidence must be raised so that he is also able to make some
constructive criticism, which is welcomed, as he is the final user
of the system.
2.4.
2.4.1
2.4.2

2.4.3

2.4.4

System Performance Requirements

Efficiency (speed, size, peripheral device usage)
Reliability
Description of Reliability Measures (accuracy, precision, consistency,
reproducibility, etc.)
Error/Failure Detection and Recovery (failure modes, failure consequences,
error logging and reporting, manual and automatic recovery procedures)
Allowable/Acceptable Error/Failure Rate
Security
Hardware Security
Software Security
Data Security
Execution Security (user validation)
Maintainability

2.4.5. Modifiability
2.4.6. Portability
2.5

Conclusion

Give a chapter conclusion

CHAPTER THREE

3. Project planning and Literature Review

3.1. Introduction
Give a chapter introduction
3.2.

Project planning and scheduling

The project developer must clearly articulate the deliverables and milestones. Students can
also using project planning tools such as bar charts, project network charts, Gantt charts etc.
Project planning software may also be used.
3.3.

Literature Review

This is a historical or conceptual survey of relevant work done in the area by previous system
developers. Each contribution must be accompanied by appropriate references to be listed in
the reference section. The developer must identify existing systems that were developed to
address the current problem and how they are inadequate or what are their weaknesses.
Further the developer must identify process models that that will be used and a justification
must be given as to why certain process models have been chosen. The user might choose
process models such waterfall, spiral, incremental etc. Be sure to choose a process model that
suits your project.
3.4.
Conclusion
Give a chapter conclusion

CHAPTER FOUR
4. System Analysis and Design
This is a top level preliminary or provisional indication of the proposed system architecture
and flow. You should correlate system functions with system structure and interface
specifications. Further the developer should analyse both the existing and new system with
the aim of obtaining a fuller understanding of the system. The developer can use
questionnaires or interviews or both when investigating about the system. The developer
must not use technical tools in the analysis. At this stage, the developer can make use of the
following tools: dataflow diagrams, decision tables and trees, ERDs, sequence diagrams, use
case diagrams, class diagrams, data dictionary, petri nets, state transition diagrams.
4.1.

Introduction
Chapter introduction

4.2.

System Architecture

4.2.1. Data Flow Diagrams (level 1 and 2 DFDs)

DFD(Data Flow Diagram)

0-Level (Context Level) DFD

User

1-Level

1.0
DFDProcess

System

1.0.0
Polling Process

Person

Login

User-Login

1.0.0
Login Process
Login

Admin
User
Login

2-Level DFD
Total No. of votes

Percentage of all
votes

Registratio
nn

User

User Details Details

TotalCandidateofVot
e
Candidate name

User Details
Poll Answer

User Details

Admin

1.0.0
Login Process

Home

TotalCandidateofVot
e

5.
Result of Candidate votes
Admin

User Details

Percent Candidate
5.2.1. Entity Relationship Diagram
This is a conceptual model of a system showing the entities and their attributes as well as the
relationships between or among entities.
5.2.2. System Structure Chart(s)
This is a (set of) chart(s) showing the functional units of the system hierarchically organized
to show which units call, use or contain other units. Each interface between two units (a call)
is annotated with small arrows and data item labels to show the data exchanged between the
units.
5.2.3. System Data Dictionary
This is a comprehensive dictionary of all the data items that appear in the system data flow
diagrams and the structure charts. At a minimum it contains, for each data item, its identifier,
any abbreviation used instead of the identifier, the name of the type of the data, and a
definition of the data item in the form of either a symbolic expression or a precise
description. The most appropriate way is to come up with data dictionary for each and every
technique that the developer would have used. The data dictionary should be part of every
project.
5.2.4. Equipment Configuration
Describe the equipment you will use to support the operation and development of your
system.

Admin database

5.3. System Data Structure Specifications

_______________

5.3.1. Other User Input Specification

4.3.1.1. Identification of Input Data
4.3.1.2. Source of Input Data (NOT input device)
4.3.1.3. Input Medium and/or Device
4.3.1.4. Data Format/Syntax
4.3.1.5. Legal Value Specification
5.3.2. Other User Output Specification
4.3.2.1.
4.3.2.2.

Identification of Output Data

Destination of Output Data (NOT output device)

4.3.2.3

Output Medium and/or Device

4.3.2.4
4.3.2.5

Output Format/Syntax
Output Interpretation (meaning of output)

4.3.3. System Data Base/File Structure Specification

4.3.3.1Identification of Data Base/Files
4.3.3.2 (Sub) systems accessing the Data Base (creating, updating, using; frequency)
4.3.3.3 Logical File Structure (record formats, file organization, access methods, rationale, examples)
4.3.3.4 Physical File Structure (storage device, blocking, organization, access, etc.)
4.3.3.5 Data Base Management Subsystems Used (internal or external)
4.3.3.6 Data Base Creation and Update Procedure (if NOT by system)
4.3.4

4.4.

System Internal Data Structure Specification

4.3.4.1.
Identification of Data Structures
4.3.4.2.
Modules Accessing Structures (creating, updating, using)
4.3.4.3.
Logical Structure of Data (format, organization, access,
rationale, examples)
Module Design specifications
4.4.1. Module Functional specification
4.4.1.1 Functions Performed
4.4.1.2 Module Interface Specifications (input/output
variables/files)
4.4.1.3 Module Limitations and Restrictions

arguments/global

4.4..2 Module operational Specification

4.4.2.1 Locally Declared Data Specifications (variable dictionary)
4.4.2.2 Algorithm Specification (flowchart, pseudo code, decision table, etc)
4.4.2.3 Description of Module Operation
4.5.

Conclusion

Chapter conclusion

CHAPTER FIVE
5

Implementation and Testing

5.1.
Introduction
Chapter introduction

5.1.

Choosing the language

List the programming languages or scripting languages you have used for the
implementation of your project and give reasons for choosing each language.

5.2.

Choice of environment

Indicate where applicable the databases that were used and justify why you chose for
instance Oracle instead of MySQL or vice versa. Indicate the operating system used
and web servers and other web authoring tools used and do not forget to justify why
you chose those tools.
5.3.
5.4.
5.5.
5.6.
5.7.

Language specific algorithm

Efficiency
Correctness
Documentation of code
Variables

5.8.

System verification/ testing

5.8.1. Items/Functions to be Tested
5.8.2. Description of Test Cases
5.8.3. Justification of Test Cases
5.8.4. Test Run Procedures and Results
5.8.5. Discussion of Test Results
5.8.6. Evaluation of User System
5.8.6.1.
Protocol Study
5.8.6.2.
User Survey
5.8.6.3.
Real Time Monitoring
5.8.6.4.
Interviews
Conclusion

5.9.

Chapter conclusion

CHAPTER SIX
6. Conclusions
6.1.
6.2.
6.3.
6.4.

Summary
Problems Encountered and Solved
Suggestions for Better Approaches to Problem/Project
Suggestions for Future Extensions to Project

REFERENCES
APPENDICES
Any other attachments

Program Listing
User manual
CDs or DVDs containing the system