Professional Documents
Culture Documents
REQUIREMENTS
SPECIFICATION FOR
E-Ballot
Registration No.
NAMIIRO MARTHA
13/U/11025/EVE
nmartha777@gmail.com
KABENGE JOSEPH
10/U/23283/EVE
Benges88@gmail.com
SoftwareRequirementsSpecificationforEBallot
Pageii
Contents
1
REVISIONS.....................................................................................................................................................................III
INTRODUCTION.............................................................................................................................................................1
2.1 DOCUMENT PURPOSE.............................................................................................................................................. 1
2.2 PRODUCT SCOPE..................................................................................................................................................... 1
2.3 INTENDED AUDIENCE AND DOCUMENT OVERVIEW................................................................................................... 1
2.3.1
Document Overview..............................................................................................................................................1
2.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS....................................................................................................... 2
2.4.1
Definitions............................................................................................................................................................2
2.4.2
Acronyms and Abbreviations................................................................................................................................2
2.5 DOCUMENT CONVENTIONS...................................................................................................................................... 2
2.5.1
Formatting Conventions.......................................................................................................................................2
2.5.2
Naming Conventions............................................................................................................................................2
2.6 REFERENCES AND ACKNOWLEDGMENTS................................................................................................................... 3
OVERALL DESCRIPTION.............................................................................................................................................4
3.1 PRODUCT PERSPECTIVE........................................................................................................................................... 4
3.1.1
Proposed Flow of Activity.....................................................................................................................................5
3.2 USER CHARACTERISTICS.......................................................................................................................................... 6
3.3 GENERAL CONSTRAINTS......................................................................................................................................... 6
3.4 ASSUMPTIONS AND DEPENDENCIES.......................................................................................................................... 6
SPECIFIC REQUIREMENTS.........................................................................................................................................6
4.1 EXTERNAL INTERFACE REQUIREMENTS.................................................................................................................... 6
4.1.1
Software Interface.................................................................................................................................................6
4.1.2
Hardware Interface:..............................................................................................................................................7
4.1.3
Communication Interface:....................................................................................................................................7
4.2 FUNCTIONAL REQUIREMENTS.................................................................................................................................. 7
4.2.1
Voters.....................................................................................................................................................................7
4.2.2
Administrator........................................................................................................................................................7
4.2.3
Candidate..............................................................................................................................................................8
4.3 BEHAVIOUR REQUIREMENTS.................................................................................................................................... 8
4.3.1
Use Case View.......................................................................................................................................................8
NON-FUNCTIONAL REQUIREMENTS......................................................................................................................9
5.1 PERFORMANCE REQUIREMENTS............................................................................................................................... 9
5.1.1
Time / space bounds..............................................................................................................................................9
5.1.2
Reliability.............................................................................................................................................................9
5.1.3
Security.................................................................................................................................................................9
5.2 SOFTWARE QUALITY ATTRIBUTES........................................................................................................................... 9
5.2.1
Availability............................................................................................................................................................9
5.2.2
Robustness............................................................................................................................................................9
SoftwareRequirementsSpecificationforEBallot
Pageiii
1 REVISIONS
Versio
n
Primary
Author(s)
Description of Version
Date
Completed
Page 1
2 INTRODUCTION
2.1 Document Purpose
The purpose of this document is to make the functional and non-functional
requirements of the e-Ballot Vote Casting System easy to comprehend. It
also serves the purpose of making the functionality clear to end users
2.3.1
Document Overview
Page 2
2.4.2
Definitions
HTML:
Hypertext Markup Language is a markup language used to
design static web pages.
CSS:
Cascade Style Sheets.
JDBC:
Java database Connector.
J2EE:
Java 2 Enterprise Edition is a programming platform part of the
Java Platformfor developing and running distributed multitier architecture
Java applications, based largely on modular software components running
on an application server.
SQL: DB2 Database is the database management system that delivers a
flexible and cost effective database platform to build robust on demand
business applications.
HTTP: Hypertext Transfer Protocol is a transaction oriented client/server
protocol between web browser & a Web Server.
WAS: Web Application Server.
HTTPS: Secure Hypertext Transfer Protocol is a HTTP over SSL (secure
socket layer).
Formatting Conventions
In general this document will follow APA formatting requirements. The entire
documents will be justified with spacing 1.15. Headings will be aligned to the left
and will be numbered according to the heading type.
2.5.2
Naming Conventions
Naming will be done mainly using paragraphs, Chapters will be in Gill Sans Font
type, 16 for Font size and automatic heading. Sections will be in Gill San MT font
type, 14 font size and normal text will be in Gill San MT font type, 12 font size.
Page 3
Olaniyan O.M, Mapayi .2T, & Adejumo. 3S.A, 2011. A Proposed Multiple Scan
Biometric-Based System for Electronic Voting. Afr J. of Comp & ICTs. Vol 4, No. 2.
pp 9-16
Rexha, B., Neziri, V., & Dervishi, R., 2012. Improving authentication and
transparency of e-Voting system Kosovo case. International Journal of Computers
and Communications, 84-91.
HTML Forms
january 2016
http://www.w3schools.com/html/html_forms.asp
accessed
on
Page 4
3 OVERALL DESCRIPTION
3.1 Product Perspective
The software product is a standalone system and not a part of a larger system.
The system will be made up of two parts. Before the Election Day, the system
will be used for general purposes such as setting up users and their privileges
and administration, entering candidate details, profiling candidates for the
election and setting the various modules before elections. The voters will reach
the system through web pages by using web-browsers such as Mozilla, Internet
Explorer and Google Chrome or by clicking on the icon of the system software on
mobiles that have finger print recognition functionality. The system will be
modular in a way that it can be used for various election i.e. it will allow for
customization.
During election, the system is connected to the thumb print database with all
the voters information. This system will be adapted to the computers at the
polling stations. The voters cast their votes using the interface that are provided
at these machines. These votes are accepted by the system on the server. The
SSL will ensure secure thumb print information transfer and easy access.
SSL
Client Interface
Finger Print Module
Finger Print
DB
HTTP
Voter DB
HTTP
The web pages (XML/JSP) are present to provide the user interface on customer
client side. Communication between customer and server is provided through
HTTP/HTTPS protocols. On the server side web server is for java servlets and
database server is for storing the information.Productfunctionality
The election admin will be able to register Candidates in the system after
their nomination. Candidates can then verify this on the system there and
then.
Page 5
Voters will be able to vote from anywhere in the area of voting, since there is
centralised control of the voting process. This will provide for convenience
and time saving
The Election Administrators will be able to update thumb print and voters
Database through a sync function with their existing voter pool available.
The sync function can be a later stage development idea.
The system would show the statistics after voting of the votes casted and
the votes obtained by the various candidates. But to reduce controversy, the
system will report after election time is closed
The system will not provide for manual input of election result by any one
user
3.1.1
Voters
Invalid
Thu
mb
ID
Valid
Voters
Activit
y
Candidates
Administrator
Log
In
Det
ails
Admin
Activit
y
Invalid
Valid
Invalid
Log
Ins
Valid
Candidat
es
Activity
Stop
Page 6
A web server should have Java installed on the machine, along with
Javas cryptographic packages.
The web server runs on an http server, that is java server pages (jsp) and
servlet enabled.
A web browser through which the voters access the server should have minimal
support for cookies and encrypted transactions.
4 SPECIFIC REQUIREMENTS
4.1 External Interface Requirements
4.1.1
Software Interface
Web Server:
Development End: WSAD (J2EE, Java, Java Bean, Servlets, XML), DB2, OS
(Windows), Web Server.
4.1.2
Hardware Interface:
Client side
Web Browser (any)
Web app
Server side
Web Application Server
SQL
4.1.3
Page 7
Ram
256 MB
256 MB
120 MB
512 MB
512 MB
Communication Interface:
4.2.1
Voters
The citizens of the country who are eligible for casting vote.
Get a Biometric ID The voters should be able to access the system
using their voter ID number and be able to generate a unique biometric
ID that they will use during elections.
Cast vote the system should the voters to cast their votes for their
favorite candidates on the system either online in their choice location
or at a gazetted place using a finger print as access authentication.
View their Details The voters will view their own details which they
filled up at the time of their registration using the system.
4.2.2
Administrator
Responsible for maintaining all the databases, generating results of polling and
nominating candidates for elections.
Register other user and Candidates Using the system, the admin
must be able to register other officer with the same privileges and also
register candidate accounts for them to view results and polling
activities.
4.2.3
Candidate
Page 8
Register for nomination, add details to profile, modify profile and campaign for
elections.
Below is a use case diagram of the whole system including the voter perspective
and then the administrator perspective?
Place
Thumb
Get BioMetric
Print
View Results
ID
View
Profile
Details
Voter
Candidate
View
Profile
Details
Cast Vote
Nominate
Candidate
View Election
Reports
Statistics
Add Candidate
Account
Add Voters
Details
Add User
Administrator
Users
Log In
Page 9
5 NON-FUNCTIONAL REQUIREMENTS
5.1 Performance Requirements
5.1.1
The system is expected to have a short response time. The user, candidate
and voters should be able to get response for their requests in less than 5
seconds in relations to their connection strength.
5.1.2
The system in all case should avail integral information to all users
The system will in all cases update changes in vote casting in all user
accounts
5.1.3
Reliability
Security
At the voting time, the e- Ballot system shall be available to users on the
network and to dial-in users 99.9% of the time between 7:00am and 5:00pm
local time for voting and 95% of the time between 5:00pm and 6:00am local
time for winner announcement.
5.2.2
Availability
Robustness
If the connection between the user and the system is broken prior to voting
being either confirmed or canceled, the E-Ballot System shall enable the
user to recover an incomplete vote casting process.
Page 10