School of Computer Science & Software Engineering
Bachelor of Computer Science (Digital Systems Security)
CSCI321- Project
Requirement Specification
11th November 2022
Group: FYP-22-S4-02
Cheong Wai Hong
7311163
whcheong004@mymail.sim.edu.s
g
Gee Wei Shaun, Colemann
7311369
wscgee001@mymail.sim.edu.sg
Hong Ter Yen
7431405
tyhong001@mymail.sim.edu.sg
Johan Bin Iskandar
7432136
johanbi001@mymail.sim.edu.sg
Kow Wei Ren
7364258
wrkow001@mymail.sim.edu.sg
Requirement Specification
FYP-22-S4-02
Supervisor : Professor Japit Sionggo
Assessor
: Mr. Ee Kiam Keong
Document Control
Title:
Requirement Specification
Document Name:
Requirement Specification
Last Change on
Owner
Current Version
Approved by
Date
Johan Bin Iskandar
version 1
Time
12th November 2022
16:30
Cheong Wai Hong
Distribution List
Name
Title/Role
Where (location where the
document is stored)
Cheong Wai Hong
Content Creator/Auditor
Google Drive
Gee Wei Shuan, Colemann
Content Creator/Auditor
Google Drive
Hong Ter Yen
Content Creator/Auditor
Google Drive
Kow Wei Ren
Content Creator/Auditor
Google Drive
Record of Revision
Revision Date
13/11/2022
Description
Minor Changes on Gantt Chart
Section Affected
Gantt Chart
Changes Made by
Cheong Wai Hong
Version after
Revision
version 1.1
Page 2 of 34
Requirement Specification
FYP-22-S4-02
Page 3 of 34
Requirement Specification
FYP-22-S4-02
Contents
Document Control
2
Introduction
5
Glossary
5
Overview
5
Requirements Definition
10
Specific Requirements
10
Functional Requirements
10
User Stories
10
Use Case Diagrams
12
Use Case Descriptions
14
System Functionalities
30
Non-functional Requirements
31
Security Requirements
31
Other Requirements
32
System Features
32
Documentation Requirements
32
Development Standard Requirements
32
Regulations such as PDPA
33
Work Breakdown Structure
Ошибка! Закладка не определена.
Gantt Chart
Ошибка! Закладка не определена.
References
34
Page 4 of 34
Requirement Specification
FYP-22-S4-02
Introduction
This document serves as a communication between all the stakeholders to illustrate and describe all the
software product behaviors and functionalities. The objective of this project is to elevate the security
features of an e-voting system by applying the homomorphic encryption cryptosystem. This document
will cover the functional requirements, non-functional requirements, security requirements, other
requirements, Work Breakdown Structure and Gantt Chart.
Glossary
Security - The protection of the computer system hardware and software from information disclosure,
unauthorized access to the system resources, data modified in the transmission means and theft of the
system resources.
Encryption - The process of converting information or data into a ciphertext, especially to prevent
unauthorized access.
Decryption - The process that transforms encrypted information (ciphertext) into its original format
Secret Key/Cryptographic Key - The piece of information or parameter that is used to encrypt and
decrypt messages
Homomorphic encryption - A form of encryption cryptosystem which allows the computation
operation to operate on its encrypted data without first decrypting it.
Overview
This scope of this project aims to integrate homomorphic encryption cryptosystem and some basic
security features into the e-voting system to be able to serve as a reliable and democratic voting service
to the users.
Homomorphic encryption is an encryption scheme that allows some specific algebraic operations on the
encrypted data (Zhao, Pan, Wang and Zhang, 2014) and when decrypting the operated encrypted data, it
will produce an identical result as the operation that operated on the original data. This property can be
achieved by structure preservation of the homomorphic encryption when encrypting the data into
ciphertext.
In homomorphic encryption, there are two properties of encryption schemes, additive and multiplicative.
For example, ElGamal Cryptosystem and Paillier Cryptosystem have two homomorphic properties.
Additive homomorphic such that 𝐸(𝑥 + 𝑦) = 𝐸(𝑥) ∗ 𝐸(𝑦), and multiplicative homomorphism such
that 𝐸(𝑥 ∗ 𝑦) = 𝐸(𝑥) ∗ 𝐸(𝑦).
Page 5 of 34
Requirement Specification
FYP-22-S4-02
A fully homomorphic encryption allows different types of algebraic operations to be performed on the
encrypted data without limitations. While in the case of partially homomorphic encryption, it only allows
one operation on the encrypted data, being either addition or multiplication.
Cloud computing and cloud storage technologies are gradually maturing, business and end users are
outsourcing performance computation and data storage due to the limited computational power within
their organization or personal computers. Under normal circumstances, a third-party needs to decrypt
the encrypted data to be able perform the requested computation, and this requires end users to send their
secret key out to the third party. This procedure risks data privacy leaks when the transmission of the
secret key may be unsecure or when the third-party may not be trusted to do their due diligence.
Since homomorphic encryption does away with the need for data to be decrypted before it can be
processed, it essentially removes another point of vulnerability that cyber criminals are able to target for
data exfiltration/theft. This protects the integrity of the company and prevents any privacy concerns in
the event the data stolen includes clients’ personal information as the data would be in encrypted form
and unable to be read by humans.
In the generic e-voting system, three main parties are involved in the voting process with separate
privileges, which are voter, teller and event owner. The voter casts the ballot, the teller counts the ballot
casted by voters and the announcer retrieves the final result of the voting event. The teller can be a third
party vendor, so their security may be fallible.
The following schemes are suggested to ensure the verifiability of the voters and privacy of the ballot
information between different entities in the generic e-voting system.
[Voter-Event Owner homomorphic encryption]
When the voting committee initiates and starts the vote event, the central system (a trusted system and
only can be accessed by the event owner(s) only) creates the public key for all the voters to encrypt their
ballots and the private key to let the event owner decrypt the result.
[Voter-Teller electronic signature by Public Key Infrastructure (PKI)]
The voter needs to sign their encrypted ballot result with the public key cryptosystem and send this
signature to the teller to be able verify themselves (Rivest, Shamir and Adleman, 1978). Thus, the voter
and teller needs to agree on a set of public key and private key to be able perform the message signature.
The teller verifies and reveals the original encrypted message (which is encrypted by the homomorphic
encryption scheme) and performs the algebraic operation. After the operation is done, the encrypted
Page 6 of 34
Requirement Specification
FYP-22-S4-02
result will be sent to the vote event committee (announcer) and they will have the privilege to decrypt
the final result as only they have the private key.
Furthermore, for the above proposed e-voting system, it assumes that the original data does not contain
any noise, so that the algebraic operation used on the encrypted data will not amplify any noise, resulting
in the encrypted result being undecipherable.
Based on the research above, we have learnt some techniques and solutions from the various research
papers and proposed our own e-voting system by employing the Homomorphic encryption scheme. For
our e-voting system, our chosen target audience are large organizations such as the government and the
prominent companies who need to elicit the public or their internal employees' ideas, interests and
opinions. Such organizations will be highly concerned with the security and integrity of the voting
mechanism in order for the voters to maintain their anonymity. In our proposed e-voting system, two
main entities will be involved in the voting process, which are Voters and Event Owners.
The Event Owner, the initiator of the e-voting campaign, will create the event based on some event
definitions (parameters) such as event name, vote question (only one question), vote options and eligible
Voters. Of course, some trivial information needs to be provided to be able support the system functions,
these will be covered in the functional section of this document. After the event owner has created and
published the vote event, the system will trigger and send out the invitation link to all the predefined
Voters.
The Voter, a personnel who provides their interests and opinions by casting their vote on the e-voting
system. The Voter needs to use their unique invitation link to access the e-voting platform, as this is a
way to ensure that only intended Voters will take part in the vote. The functionality of the Voter will be
limited, in which he/she only can cast their vote by submitting the result on the system. Voters need not
worry about registering for the vote event, as the Event Owner will define who are eligible to participate.
This minimizes the security risk as the Voters no longer need to register on the event, putting their details
into the system where info might leak, assuming that all the Voters defined by the Event Owner are
genuine users.
When the vote event ends, the system will be triggered to start tallying the votes. Once the final result is
ready, the Event Owner can instruct the system to publish the final result to all the Voters. By preventing
the non-related personnel access and getting the final result, the system will generate a unique link for
the event final result webpage and send out to all the predefined participating Voters only. Assuming
that Voters do not share this information to the public.
Page 7 of 34
Requirement Specification
FYP-22-S4-02
To achieve the security and integrity of the system data, all the data transfer between the users and the
system will be employed using some scheme of the existing cryptosystem. To be able to tally the vote
without knowing the facts of it, we employ the homomorphic encryption scheme when processing the
Voter submission data and tally the vote by using its additive/multiplicative property of the cryptosystem.
Some assumption for our proposed e-voting system are made, such as follow:
1. Voters do not share or exploit their invitation link
2. Voters do not share or exploit the final result link
3. Voters do not disclose or share their email accounts with others
4. Event Owner does not disclose the vote event information to the public
5. Event Owner is only authorized to access the vote final results, not the individual voter
information
There are few existing e-voting systems implementing homomorphic encryption in the market, such as
Helios Voting (https://vote.heliosvoting.org) and Belenios (https://www.belenios.org/index.html).
Which are quite new for us and we have not seen these platforms before.
Current existing homomorphic encryption API libraries are Microsoft SEAL from Microsoft Corporation
and HElib from IBM Corporation (this is not an exhaustive list). These libraries are all written in C++
language. In our proposed e-voting system, we will employ the existing public-key infrastructure
cryptosystem which possesses the homomorphic property, which is additive and/or multiplicative.
Lastly, there is a possible application of Homomorphic encryption scheme in real world e-hailing
systems. E-hailing providers (such as Grab, Uber and etc.) can employ the homomorphic property to
protect the user and driver location data. When the system calculates the trip routes for the users,
homomorphic operation can be employed so that the user location data will not be exposed to third-party
vendors, such as the e-hailing platform itself. However, there is still not a completely secure scheme to
protect the user location data privacy, since the attacker/sneaker might be a genuine user under the
system, let say the driver user. Further strategies need to be discovered to be able present a fully secured
e-hailing system in real-world usage.
However, implementing Fully Homomorphic Encryption (FHE) comes at a cost to business owners such
as those e-hailing platforms mentioned above. By implementing FHE, even the business owners are not
able to view customer information and data that is encrypted. Even though this bolsters security of
customer data, companies may be apprehensive about this technology as it may not give them benefits
Page 8 of 34
Requirement Specification
FYP-22-S4-02
from a revenue perspective. Without access to customer data, they are unable to tailor their services to
better suit their customers needs and end up falling short of customer expectations, and fading from
relevance.
Page 9 of 34
Requirement Specification
FYP-22-S4-02
Requirements Definition
This section covers all the vital requirements such as functional, non-functional and security. Other
relevant requirements will be covered in this section as well such as system features, documentation
requirements and so on. To better illustrate and introduce the functional requirements in a more extensive
and clear way, UML tools such as use case diagrams and descriptions are employed as an aid to depict
the user stories and the functionalities.
Specific Requirements
In our proposed e-voting system, it should be able to perform the homomorphic encryption on the casted
votes and perform a defined algebraic operation on the encrypted votes in the tally process.
Functional Requirements
This section covers all the system functionalities. Two actors are identified who will be using and
interacting with the e-voting system, voter and event owner.
User Stories
Table 1 lists all the user stories and their respective user stories ID for actor voter and event owner.
ID
User Story
1
As a Voter, I want to be able to access the vote event through an invitation link provided
by the Event Owner so that I can participate in the specific voting event.
2
As a Voter, I want to be able to cast a vote for my preferred candidate on the voting
form so that I can present my decision at the vote event.
3
As a Voter, I want to be able to view the final vote result so that I can obtain and verify
the poll result.
4
As an Event Owner, I want to be able to create an account so that I can authenticate
myself when accessing the system resources.
As an Event Owner, I want to be able to request OTP values in account registration so
that I can verify myself in the account registration.
Page 10 of 34
Requirement Specification
FYP-22-S4-02
5
As an Event Owner, I want to be able to login to my account so that I can access the
features available to me.
6
As an Event Owner, I want to be able to log out so that I can leave the system securely.
7
As an Event Owner, I want to be able to create a voting event so that I can gather the
voters’ feedback.
8
As an Event Owner, I want to be able to view the vote event so that I can view the
details of the specific vote event.
As an Event Owner, I want to be able to view the list of vote events so that I can get
an overview on my owned vote events.
9
As an Event Owner, I want to be able to modify a created vote event so that I can
manipulate the parameters of which the event will adhere to.
10
As an Event Owner, I want to be able to delete a voting event so that I can completely
remove the event and the information associated with it.
11
As an Event Owner, I want to be able to confirm the vote event so that the voters can
participate in the vote event.
12
As an Event Owner, I want to be able to view the final vote result so that I can be
informed of the outcome of the voting event.
13
As an Event Owner, I want to be able to publish the final vote result so that all the
participating voters can view the final voting result.
14
As an Event Owner, I want to be able to view previous event information so that I can
view the information or examine all of my previously created voting events.
Table 1 - User Stories
Page 11 of 34
Requirement Specification
FYP-22-S4-02
Use Case Diagrams
Diagram 1 and 2 show all the user stories and are identified by their respective user story ID.
Actor: Voter
Diagram 1 - Use case diagrams for Voter
Page 12 of 34
Requirement Specification
FYP-22-S4-02
Actor: Event Owner
Diagram 2 - Use case diagrams for Event Owner
Page 13 of 34
Requirement Specification
FYP-22-S4-02
Use Case Descriptions
This section covers each of the use case descriptions in detail. Information such as the pre-condition,
post-condition, normal flows and alternative flows are provided in each of the descriptions tables.
Name: Access the Vote Event through the Invitation Link
ID: 1
Stakeholders and goals: Voter - Access System through the Invitation Link
Descriptions: As a voter, I want to be able to access the vote event through an
invitation link provided by the Event Owner so that I can participate in the specific
voting event.
Pre-condition:
1. Event Owner has created a voting event
2. Event Owner has sent out the invitation links via email.
Post-conditions:
1. N/A
Trigger: Voter clicks on the invitation link in their email.
Normal Flow:
1. Voter clicks on the invitation link in their email
2. Voter is redirected to the Voting form URL
3. System displays the voting form according to the Voting Event.
Alternative Flow:
3a. Invalid/Expired URL: System display the message page
3b. Used URL (casted): System display the message page
Page 14 of 34
Requirement Specification
Name: Cast a Vote
FYP-22-S4-02
ID: 2
Stakeholders and goals: Voter - Cast a Vote for a preferred candidate
Descriptions: As a voter, I want to be able to cast a vote for my preferred candidate on
the voting form so that I can contribute to the final vote count.
Pre-condition:
1. Voter is on the Voting form page
Post-conditions:
1. The casted information must be written into the system database
Trigger: Voter chooses the option he/she wants to vote for by selecting the respective option
in the webform
Normal Flow:
1. Voter chooses the option he/she wants to vote for by selecting the respective option in
the webform.
2. Voter clicks on the “Submit” button to cast their vote.
3. System displays a pop-up box to confirm the voter’s choice.
4. Voter clicks on the “Confirm” button on the pop-up box to confirm and submit their
vote.
Alternative Flow:
4a. Voter cancels the submission: system control go back to the webform state and
repeat the steps from one (the system database must not write any information)
Page 15 of 34
Requirement Specification
Name: View Final Vote Result
FYP-22-S4-02
ID: 3
Stakeholders and goals: Voter - View Final Vote Result
Descriptions: As a voter, I want to be able to view the final vote result so that I can
obtain and verify the poll result.
Pre-condition:
1. The Voting Event has ended.
2. Event Owner has published the Final Vote Result.
Post-conditions:
1. N/A
Trigger: Voter clicks on the link for the “Final Vote Result” page in their email.
Normal Flow:
1. Voter clicks on the link for the “Final Vote Result” page in their email.
2. System loads the “Final Vote Result” page.
3. Voter views the outcome of the voting event and verifies the poll result on the “Final
Vote Result” page.
Alternative Flow:
N/A
Page 16 of 34
Requirement Specification
Name: Create an Account
FYP-22-S4-02
ID: 4
Stakeholders and goals: Event Owner - Create an Account
Descriptions: As an Event Owner, I want to be able to create an account so that I can
authenticate myself when accessing the system resources.
Information required to be able successfully create an account:
4. Email
5. Username
6. Password
Pre-condition:
1. N/A
Post-conditions:
1. The newly created account information must be written into the system database
Trigger: Event Owner navigates to the “Register Account” page.
Normal Flow:
1. Event Owner clicks and accesses the register account page
2. Event Owner fills the webform with the necessary information
3. Event Owner clicks on the “Register” button.
4. Event Owner is redirected to the “Home Page”.
Alternative Flow:
3a. Form Validation Failed: Event Owner being prompted to correct the field’s information
3b. Incorrect OTP : Event Owner being prompted to provide the correct OTP values or
repeat from step 3b
Page 17 of 34
Requirement Specification
Name: Get OTP values in account registration
FYP-22-S4-02
ID:
Stakeholders and goals: Event Owner - Get OTP values in account registration
Descriptions: As an Event Owner, I want to be able to request OTP values in account
registration so that I can verify myself in the account registration.
Pre-condition:
1. Provided Email address complies with the standard email format.
Post-conditions:
1. The new OTP values will be created and written into the system database.
Trigger: Event Owner clicks the “Get OTP” button.
Normal Flow:
1. Event Owner fills in the email address in the input box on the register account page.
2. Event Owner clicks on the “Send OTP” button.
3. Event Owner obtains the OTP from their email account.
Alternative Flow:
2a. Email field is empty: Event Owner prompt to provide the email address
2b. Get a new OTP: Event Owner gets a new OTP by clicking on the “Resend OTP”
button
Page 18 of 34
Requirement Specification
Name: Login
FYP-22-S4-02
ID: 5
Stakeholders and goals: Event Owner - Login
Descriptions: As an Event Owner, I want to be able to login to my account so that I
can access the features available to me.
Information required to be able to login into the system:
1. Username
2. Password
Pre-condition:
1. Event Owner has previously created an account.
Post-conditions:
1. Event Owner login record should be written into the system’s database
Trigger: Event Owner navigates to the “Login” page.
Normal Flow:
1. Event Owner click and access the “Login” page
2. Event Owner fills in the necessary information on the login form.
3. Event Owner clicks on the “Login” button.
4. Event Owner redirected to the “Home Page”.
Alternative Flow:
4a. Login credentials incorrect: Event Owner prompted with login fail messages.
Page 19 of 34
Requirement Specification
Name: Logout
FYP-22-S4-02
ID: 6
Stakeholders and goals: Event Owner - Logout
Descriptions: As an Event Owner, I want to be able to log out so that I can leave the
system securely.
Pre-condition:
1. Event Owner is currently logged in.
Post-conditions:
1. N/A
Trigger: Event Owner clicks on the “Logout” button.
Normal Flow:
1. Event Owner clicks on the “Logout” button.
2. System redirects the Event Owner to the “Login” page.
Alternative Flow:
N/A
Page 20 of 34
Requirement Specification
Name: Create a Voting Event
FYP-22-S4-02
ID: 7
Stakeholders and goals: Event Owner - Create a Voting Event
Descriptions: As an Event Owner, I want to be able to create a voting event so that I
can gather the voters’ feedback.
Information needed to provide when creating the vote event:
1. Event Title
2. Start Date and Time
3. End Date and Time
4. Event question
5. Vote Options [List]
6. Participating voter emails [List]
Pre-condition:
1. Event Owner is logged in.
Post-conditions:
1. The successfully created event information must be written into the database system
Trigger: Event Owner clicks on the “Create New Voting Event” button in the “Home Page”.
Normal Flow:
1. Event Owner clicks on the “Create New Voting Event” button in the “Home Page”.
2. Event Owner being redirected to the “Create Voting Event” page.
3. Event Owner fills in the necessary information into the webform
4. Event Owner clicks on the “Create Event” button.
5. Event Owner prompted with an event creation successful message
6. Event Owner redirected to the “Home Page” with reflected changes.
Alternative Flow:
5a. Form Validation Failed: Event Owner needs to correct the invalid fields information
and repeat the steps from step 3.
Page 21 of 34
Requirement Specification
Name: View Voting Event
FYP-22-S4-02
ID: 8
Stakeholders and goals: Event Owner - View a Voting Event
Descriptions: As an Event Owner, I want to be able to view the vote event so that I
can view the details of the specific vote event.
Pre-condition:
7. Event Owner is currently logged in.
8. The vote event being viewed is created.
Post-conditions:
1. N/A
Trigger: Event Owner clicks on the “View” button of the dedicated vote event in the “Home
Page”.
Normal Flow:
2. Event Owner clicks on the “View” button of the dedicated vote event in the “Home
Page”.
3. Event Owner get redirected to the page with the selected vote event’s information
Alternative/Exceptional flows:
N/A
Page 22 of 34
Requirement Specification
Name: View The List of Voting Events
FYP-22-S4-02
ID:
Stakeholders and goals: Event Owner - View The List of Voting Events
Descriptions: As an Event Owner, I want to be able to view the list of vote events so
that I can get an overview on my owned vote events.
Pre-condition:
1. Event Owner is currently logged in.
Post-conditions:
1. N/A
Trigger: Event Owner navigates to “Home Page”.
Normal Flow:
1. Event Owner navigates to “Home Page”
2. Event Owner gets a list of information of all owned vote events.
Alternative/Exceptional flows:
N/A
Page 23 of 34
Requirement Specification
Name: Modify Voting Event
FYP-22-S4-02
ID: 9
Stakeholders and goals: Event Owner - Modify Voting Event
Descriptions: As an Event Owner, I want to be able to modify a created voting event
so that I can change the parameters of which the event will adhere to.
Information can be modified for the vote event:
1. Event Title
2. Start Date and Time
3. End Date and Time
4. Event question
5. Vote Options [List]
6. Participating voter emails [List]
Pre-condition:
1. Event Owner is currently logged in.
2. The Vote event being modified is created.
Post-conditions:
1. The modification on the vote event need to be written into the system’s database
Trigger: Event Owner clicks on the “Modify” button next to the vote event he/she wishes to
modify.
Normal Flow:
1. Event Owner clicks on the “Modify” button next to the event he/she wishes to modify.
2. System redirects the Event Owner to the “Modify Voting Event” page.
3. Event Owner updates the necessary information in the webform.
4. Event Owner clicks on the “Apply Changes” button.
5. Event Owner redirected to the Home Page.
6. Event Owner can view the reflected changes on the Home page.
Alternative Flow:
4a. Form Validation Failed: Event Owner needs to correct the invalid field information and
repeat the steps step 3.
Page 24 of 34
Requirement Specification
Name: Delete Voting Event
FYP-22-S4-02
ID: 10
Stakeholders and goals: Event Owner - Delete Voting Event
Descriptions: As an Event Owner, I want to be able to delete a voting event so that I
can completely remove the event and the information associated with it.
Pre-condition:
1. Event Owner is currently logged in.
2. The vote event being deleted is created.
Post-conditions:
1. The records and all the associated information of the vote event must be erased from
the system’s database.
Trigger: Event Owner clicks on the “Delete” button next to the event he/she wishes to delete.
Normal Flow:
1. Event Owner clicks on the “Delete” button next to the event he/she wishes to delete.
2. System displays a pop-up box to confirm if the Event Owner wishes to delete the
Voting Event along with a message.
3. Event Owner clicks on the “Yes” button to confirm the deletion of the Voting Event.
4. Event Owner can view the reflected changes on the Home page.
Alternative Flow:
3a. Event Owner click “No”: Flow terminates
Page 25 of 34
Requirement Specification
Name: Confirm the Vote Event
FYP-22-S4-02
ID: 11
Stakeholders and goals: Event Owner - Confirm the Vote Event
Descriptions: As an Event Owner, I want to be able to confirm the event so that the
voters can participate in the vote event.
Pre-condition:
1. Event Owner is currently logged in.
2. The Vote event being confirmed is created.
Post-conditions:
1. Vote Event state has been updated in the system’s database
2. The invitation links are generated and sent to the voters’ email address
Trigger: Event Owner clicks on the “Confirm” button next to the event he/she wishes to start
the voting process on.
Normal Flow:
1. Event Owner clicks on the “Confirm” button next to the event he/she wishes to start the
voting process on.
2. System displays a pop-up confirmation box.
3. Event Owner clicks on the “Yes” button.
4. Event Owner gets an acknowledgement message from the system.
5. Event Owner clicks on the “Close” button to close the message.
Alternative Flow:
3a. Event Owner click “No”: Flow terminates
Page 26 of 34
Requirement Specification
Name: View Final Vote Result
FYP-22-S4-02
ID: 12
Stakeholders and goals: Event Owner- View Final Vote Result
Descriptions: As an Event Owner, I want to be able to view the final vote result so that
I can be informed of the outcome of the voting event.
Pre-condition:
1. Event Owner is currently logged in.
2. The Voting Event has ended.
3. The tally/counting process on the vote event has been done
Post-conditions:
1. N/A
Trigger: Event Owner clicks on the “View Final Result” button next to the event he wishes to
view the Final Voting Result for.
Normal Flow:
1. Event Owner clicks on the “View Final Result” button next to the event he wishes to
view the Final Voting Result for.
2. Event Owner redirected to the “Final Voting Result” page for the selected Voting
Event.
3. Event Owner views the results as well as the related information for the Voting Event.
Alternative Flow:
2a. Tally/Counting Process in progress : Display the message to the Event Owner and
terminates the flow
Page 27 of 34
Requirement Specification
Name: Publish Final Vote Results
FYP-22-S4-02
ID: 13
Stakeholders and goals: Event Owner- Publish Final Vote Results
Descriptions: As an Event Owner, I want to be able to publish the final vote result so
that all the participating can view the final voting result.
Pre-condition:
1. Event Owner is currently logged in.
2. The Voting Event has ended.
3. The tally/counting process on the vote event has been done
Post-conditions:
1. N/A
Trigger: Event Owner clicks on the “View Final Result” button next to the event he wishes to
view the Final Voting Result for.
Normal Flow:
1. Event Owner clicks on the “View Final Result” button next to the event he wishes to
view the Final Voting Result for.
2. Event Owner redirected to the “Final Voting Result” page for the selected Voting
Event.
3. Event Owner clicks on the “Publish Results” button.
4. System displays a pop-up box to confirm if the Event Owner wishes to publish the
Final Vote Result along with a message.
5. Event Owner gets an acknowledgement message.
6. Event Owner clicks on the “Close” button to close the message box.
7. Event Owner redirected to the “Home page” with the reflected changes.
Alternative Flow:
2a. Tally/Counting Process in progress : Display the message to the Event Owner and
terminates the flows
4a. Event Owner clicks “No”: Flow terminates
Page 28 of 34
Requirement Specification
Name: View Previous Final Results
FYP-22-S4-02
ID: 14
Stakeholders and goals: Event Owner- View Previous Final Results
Descriptions: As an Event Owner, I want to be able to view previous final vote results
so that I can view the final voting result of all of my previously created voting events.
Pre-condition:
1. Event Owner is currently logged in.
Post-conditions:
1. N/A
Trigger: Event Owner clicks on the “History of Voting Events” button.
Normal Flow:
1. Event Owner clicks on the “History of Voting Events” button.
2. Event Owner being redirected to the “History of Voting Events” page.
3. Event Owner can view all previously “Completed” Voting Events as well as their
relevant details.
Alternative Flow:
N/A
Page 29 of 34
Requirement Specification
FYP-22-S4-02
System Functionalities
This section covers all the system functions needed to be able support the functions as depicted in the
user stories.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Authenticate the Event Owners
Generate, send and authenticate new users (event owners) with one time password via email.
Authenticate the voters by voter’s unique invitation link
Process and store the information for each vote event
Generate the respective cryptographic keys for each vote event
Generate a list of unique invitation links for each of the participating voters of the vote event
Send out the invitation email to the participating voters of the vote event
Open and activate the vote access to the voters during the event predefined date and time
Authenticate the voters when they access using their unique invitation link
Dynamically generate the user interface page when the voter accesses the system based on the
vote event information provided by the event owner.
Process and store the vote data by using Homomorphic encryption scheme.
Tally and count the vote data in the encrypted form.
Process and display the tallied vote data associated with each casted vote information.
Generate and send out the vote event final result as a web page link to all the participated voters.
Page 30 of 34
Requirement Specification
FYP-22-S4-02
Non-functional Requirements
1.
2.
3.
4.
5.
6.
7.
8.
The system should be responsive to the event/action instructed by the users
The system design should be intuitive, clear and user friendly to provide the service to the users.
The system should be able extend its functionality or its coverage on more users in the future
The system should be able to run over different version of the web browser
The system should be able to run over different operating platforms and different browsers
The system should be able to recover and revert back to service state from some error states.
The system should be up and serve its functionalities to the user 24/7.
The system should be patched or upgraded to repair its existing defects with a low system
downtime (low meantime to repair).
Security Requirements
1. Strong password policy and protection by storing the Event Owner’s password in the hashed
2.
3.
4.
5.
6.
7.
8.
form.
Authentication on every user before allowing access into the system. This covers the personnel
of:
a. Voters: By the invitation link
b. Event Owner: By their login credentials
Privacy and Anonymity of the voter, by encrypting the Voter relevant information and storing
the encrypted form in the system’s database
Uniqueness of vote by deleting the vote link after the Voter has casted their vote
Verifiability of the final vote result, which the voter can verify his/her casted vote counted
correctly by checking their receipt number on the final result page.
Input Sanitization, as all the input from users need to be checked and raise the warning to the
system admin if there are any vulnerabilities. Attacks such as SQL Injection can be prevented
here.
Cross site scripting forgery prevention to prevent the attacker from acting on the genuine users
behalf.
Brute Force attack prevention which the users will be allowed to attempt to log in 5 times
before the account is soft locked for 5 minutes. An email will be sent to the user notifying them
of the failed attempts in case those were done by a malicious actor trying to gain access.
9. reCAPTCHA on Event Owner account registration to prevent the system being spammed by bots
and abused by the attacker.
Page 31 of 34
Requirement Specification
FYP-22-S4-02
Other Requirements
System Features
1. [System Architecture] The system product will consist of a client browser (can be more than one),
and a web server machine consisting of Django architecture and a database server to be able fully
present its functionalities.
a. Django Architecture
i.
Model
ii. View
iii. Templates
iv.
Helper modules
v.
Vote Tallying module
2. [Software Architecture] The software product will consist of 3 technology stacks.
a. Front end - HTML/CSS/JS
b. Backend - Python/Django
c. Database - Relational Database, MySQL
Documentation Requirements
1.
2.
3.
4.
5.
All system functionalities and security functionalities should be documented accordingly
System design outcomes such as diagrams and algorithms should be documented
Changelog regarding the code base should be documented
Test plan, test log/report and system defects discover report should be documented
System setup guide, user guide and troubleshooting guide should be produced as a part of system
product
Development Standard Requirements
Each sprint may last for two weeks, we will be conducting the sprint meeting in the middle of the sprint
and at the end of the sprint. Each sprint meeting will update the team for the respective task progressions.
In every sprint the following tasks will be carried out:
1. Function technical designs
2. Functional implementation
3. Functional testing
4. Functional integration (with testing) and delivery
5. Closure with increment documentation
Page 32 of 34
Requirement Specification
FYP-22-S4-02
Before the agile sprint starts, tasks will be allocated among the team members to be executed and
implemented. Each sprint has its own goals, requirements and deadlines to be set and achieved. As
mentioned previously, deliverables and deadlines of each sprint will be documented as a series of
separate documents to be well communicated within the team.
Regulations such as PDPA
1. All vote related data will be stored in the encrypted form in the database
2. Disclosure of voter personal data is prohibited, unless the Event Owner has a right to do so.
3. Retention of voter personal information as for Event Owner verify and authenticate the voter
eligibility purpose
Page 33 of 34
Requirement Specification
FYP-22-S4-02
References
[1] Zhao, Y., Pan, Y., Wang, S. and Zhang, J., 2014. An anonymous voting system based on
homomorphic encryption. 2014 10th International Conference on Communications (COMM),.
[2] Azougaghe, A., Hedabou, M. and Belkasmi, M., 2015. An electronic voting system based on
homomorphic encryption and prime numbers. 2015 11th International Conference on Information
Assurance and Security (IAS),.
[3] Rivest, R., Shamir, A. and Adleman, L., 1978. A method for obtaining digital signatures and publickey cryptosystems. Communications of the ACM, 21(2), pp.120-126.
Page 34 of 34