Download as xlsx, pdf, or txt
Download as xlsx, pdf, or txt
You are on page 1of 8

Accenture Online Voting Pilot for Australian Federal Government - Requirements Analysis - Ballot Related Functions

Collaboration Zone Link: AUSOnlineVoting/ACCSlack.com ***

Req # Module Submodule


0.5 Ballot Notional

5.1.0 Ballot Security

5.1.1 Ballot Security

5.1.2 Ballot Security

5.1.3 Ballot Security


5.1.4 Ballot Security
5.1.5 Ballot Security
5.1.6 Ballot Security
5.2.0 Ballot Header

5.2.1 Ballot Header


5.2.2 Ballot Header

5.2.3 Ballot Header

5.2.4 Ballot Header


5.2.5 Ballot Header
5.2.6 Ballot Header
5.3.0 Ballot Line Items

5.3.1 Ballot Line Items

5.3.2 Ballot Line Items


5.3.3 Ballot Line Items
5.2.4 Ballot Line Items

5.2.5 Ballot Line Items


5.2.6 Ballot Line Items
5.2.7 Ballot Line Items
5.2.8 Ballot Line Items
g Pilot for Australian Federal Government - Requirements Analysis - Ballot Related Functions

AUSOnlineVoting/ACCSlack.com ***

Requirement
Ballots should be dynamically created based on a secure Ballot Setup function.
That function will also specify what roles can access the ballot, when and for how
long, and potentially support notification via text message. Ability for a user to
change their vote before the period closes should be an option.

Ballots should be data driven without any hardcoding. Ballots must support
multiple choice with write-in options, Yes/No/Abstain/No Vote, and list of priorities
voting (i.e., score multiple selections from a list)
Security on all modules is the most important requirement, this includes secure
user validation, internal security as sell as security from potential outside hackers
Only authorised government employees should be able to access the Ballot
Creation system, subject to current federal systems internal logon restrictions

Participants from multiple federal, state, and/or local organisations should be able
to create ballots and administer the election process

Each ballot, during creation and editing, should be restricted to a specific set of
users

After a ballot is published no further changes can be made

Ballot Header should include Title and Tag Lines that carry through the user
interface, along with a free text instruction block
Ballot Header should indicate the date/time range that voting will be available
Ballot Header should specify which voters can participate in the election

Ballot header should have a flag that indicates whether or not a voter can change
their vote during the voting period

A graphical UI should be established that allows for multiple votes on a single


ballot (e.g., elect several positions and/or vote on multiple questions)
The option to create a multiple selection choice as a single Ballot Line Item (i.e.,
choice between multiple candidates for a specify position)
Each Line Item provides a tag line and area for instructions
In addition to Multiple Choice there should be a yes/no type of line item

Voters should be able to abstain or skip a vote line item, subject to validation rule
(Flag in Line Item Definition)
Questions to be asked in Requirements Phase
Original Requirements from Susan

Confirm - Requirement for Federal Employees


Question - How would we apply the standard to non-federal
employees (state/local, etc.)

Question - Is there a central registry of these users?


Question - If not, should we create an application-based user
list that meets the federal standard (i.e., a secondary login)?

Question - Should this be limited to a set of Ballot


Administrators?
How would we filter this list to ensure agency level security
(Org, Region, Department, etc.)?
Discuss Publishing - it’s key to security
Your Question
Your Question

Question: What type of hierarchy is required for ballot access


and how many levels? Will Org/Agency/Geography be
adequate for the pilot?

Confirm if needed for pilot.

Your Question
Your Question
Your Question
Confirm and Discuss
Question: Should we allow for a "write in" for certain ballots
Your Question
Your Question
Your Question
Notes
Original Ballot related Requirements from Susan. Decompose to multiple requirements based on
emerging functional Design

Note - Cross Map to Voter Maintenance <module

You might also like