Elections ACT
Upgrade of eVACS® for the 2020
ACT Legislative Assembly Election
System Specification - Part 1
Requirements
Document Status: Final
Version 1.3
August 2020
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 3
Document Control Information
The control ed version of this document is in electronic form.
Al hardcopy versions are uncontrolled.
Modifications
Date of this
Version Comment
Author
Reviewer Release
Revision
2019-08-05
0.1
Initial Draft
CJB
RB
2019-09-22
0.2
Split of System Specification into two Parts -
CJB
RB
Expanded draft of Part 1 Requirements
2019-09-27
0.3
Minor edits incorporated together with
CJB
documentation tree
2019-11-27
1.0
Edits after review by EACT and CCP003
CJB
2019-11-27
2019-12-09
1.1
Further edits
CJB
2019-12-30
2020-06-20
1.2
Edits to reflect changed requirements, including
CJB
menu items & new document tree
2020-08-06
1.3
Requirement 89 changed to reflect actual wording
CJB
2020-08-06
of Data Entry Supervisor menu
Distribution
Name and Appointment
Document Name
Date of Issue
Version
Jiv Sekhon, eVACS Project Manager, EACT System Specification Part 1
2019-10-07
0.3
Ro Spence, Deputy Electoral
Commissioner, EACT
Jiv Sekhon, eVACS Project Manager, EACT System Specification Part 1
2019-11-27
1.0
Ro Spence, Deputy Electoral
Commissioner, EACT
Jiv Sekhon, eVACS Project Manager, EACT System Specification Part 1
2019-12-30
1.1
Ro Spence, Deputy Electoral
Commissioner, EACT
Jiv Sekhon, eVACS Project Manager, EACT
2020-08-06
1.3
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 4
Contents
COPYRIGHT NOTICE ............................................................................................ 2
Disclaimer ........................................................................................................................................... 2
eVACS® ............................................................................................................................................. 2
eVACS® Upgraded Document Tree .................................................................................................. 2
DOCUMENT CONTROL INFORMATION .............................................................. 3
Modifications ....................................................................................................................................... 3
Distribution .......................................................................................................................................... 3
CONTENTS ............................................................................................................ 4
LISTS OF TABLES & FIGURES ............................................................................ 6
1. SCOPE .......................................................................................................... 7
1.1 Identification ............................................................................................................................. 7
1.2 Document overview .................................................................................................................. 7
1.2.1
Definitions, requirements and actions .................................................................................... 7
1.3 Reference Documents.............................................................................................................. 8
2
ACRONYMS .................................................................................................. 9
3
REQUIREMENTS ........................................................................................ 10
3.1 Introduction ............................................................................................................................. 10
3.2 System capability requirements ............................................................................................. 10
3.2.1
Overview of components ...................................................................................................... 10
3.2.2
Election terminology ............................................................................................................. 16
3.2.2.1 Elections ............................................................................................................................... 16
3.2.2.3 Ballot type, vote formality, and interpretations and Votes ..................................................... 17
3.2.2.4 Ballot rotation ....................................................................................................................... 18
3.2.2.5 Polling places ....................................................................................................................... 18
3.2.2.6 Vote interpretation ................................................................................................................ 18
3.2.2.7 Counting system ................................................................................................................... 19
3.2.3
Requirements on rotations ................................................................................................... 19
3.2.4
General Requirements ......................................................................................................... 20
3.2.4.1 Auditing ................................................................................................................................ 20
3.2.4.2 Errors and exceptions .......................................................................................................... 21
3.2.4.3 Languages other than English .............................................................................................. 21
3.2.5
Election setup ....................................................................................................................... 21
3.2.6
Electronic Voting .................................................................................................................. 22
3.2.6.1 Barcodes .............................................................................................................................. 23
3.2.6.2 Ballot legibility ....................................................................................................................... 24
3.2.6.3 Ballot flexibility ...................................................................................................................... 25
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 5
3.2.6.4 Requirements specific to the voting client ............................................................................ 25
3.2.6.4.1 States ................................................................................................................................... 25
3.2.6.4.2 Welcome Screen .................................................................................................................. 26
3.2.6.4.3 Main Voting Screen .............................................................................................................. 26
3.2.6.4.4 Confirmation Screens ........................................................................................................... 27
3.2.6.4.5 Hidden Vote Screen ............................................................................................................. 28
3.2.6.4.6 Start Again Screen (Clear Choices screen) .......................................................................... 28
3.2.6.4.7 Acknowledgement Screen (Acceptance screen) .................................................................. 28
3.2.6.4.8 Voting Stores ........................................................................................................................ 29
3.2.6.4.9 Reset .................................................................................................................................... 29
3.2.6.5 Requirements specific to the polling place voting server ...................................................... 29
(see section 3.2.7 for telephone voting server) ..................................................................................... 29
3.2.7
Telephone voting .................................................................................................................. 30
3.2.7.1 PINs and Voting Tokens ....................................................................................................... 31
3.2.8
Data entry and counting ....................................................................................................... 31
3.2.8.1 Data entry concepts ............................................................................................................. 31
3.2.8.2 Data entry client ................................................................................................................... 32
3.2.8.2.1 Data entry ............................................................................................................................. 32
3.2.8.2.2 Data entry performance constraints ..................................................................................... 33
3.2.8.2.3 Data entry correction and batch control ................................................................................ 33
3.2.9
Election server - Data entry server ....................................................................................... 34
3.2.10
Electronic voting counting and reporting .............................................................................. 34
3.3 System interface requirements .............................................................................................. 35
3.3.1
System external interface identification ................................................................................ 35
3.3.2
System internal interface identification ................................................................................. 36
3.4 System internal data requirements ........................................................................................ 37
3.5 Safety requirements ............................................................................................................... 37
3.6 Security and privacy requirements ......................................................................................... 37
3.6.1
Requirement to be satisfied by a system component ........................................................... 38
3.7 Computer resource requirements .......................................................................................... 39
3.7.1
Hardware requirements ........................................................................................................ 39
3.7.1.1 Election servers .................................................................................................................... 39
3.7.1.2 Electronic ‘clients’ ................................................................................................................. 39
3.8 System quality factors ............................................................................................................ 41
3.9 Design and construction constraints ...................................................................................... 41
3.9.1
Voting client .......................................................................................................................... 41
3.9.2
Training related requirements ............................................................................................... 42
3.9.3
Logistic related requirement ................................................................................................. 42
3.10
Qualifications provisions .................................................................................................... 42
4
REQUIREMENTS TRACEABILITY ............................................................. 43
APPENDIX A - PERMUTATION EXPLANATIONS ............................................. 44
Permutation ...................................................................................................................................... 44
Size of Permutation .......................................................................................................................... 44
APPENDIX B – SCREENS IN VOTING PROCESS ............................................. 45
Actions possible from each screen ................................................................................................... 45
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 6
Lists of Tables & Figures
Table 1 - List of Definitions .................................................................................................................... 11
Table 2 - 2020 List of Requirements ..................................................................................................... 12
Table B.1 - Possible actions from each screen and progress bar indications……………………………46
Table B.2 – Wording of messages and instructions on each screen………………………………………47
Figure 1 - System context diagram ....................................................................................................... 36
Figure 2 - Keypad functions for BV&I setup at pol ing places ............................................................... 40
Figure 3 - Key functions for telephone voting ........................................................................................ 40
Figure 4 - Key pad for data entry ........................................................................................................... 41
Figure B.1 – Screens in voting process………………………………………………………………………45
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 7
1. Scope
The System Specification (SSS) specifies the system structure and requirements for eVACS® Upgraded
and the methods to be used to ensure each requirement has been met.
The SSS has been derived from the Operational Concept Description (OCD)[3]; in turn it is to be used
as the basis for modelling, design, and quality testing of the system.
There are two parts to the SSS:
Part 1 – Requirements, (this document) including election nomenclature definitions as used in eVACS®
Upgraded, and
Part 2 - Scenario Analyses, in the form of Event-Action lists reflecting the requirements for the upgraded
eVACS®.
Commencing with Part 1 version 1.3 and Part 2 version 1.2, contract change requirements have been
incorporated into the SSS.
1.1 Identification
This document applies to the upgraded version of eVACS® to be used by Elections ACT (EACT) in the
2020 ACT Legislative Assembly Election. It is referred to as SSS-1-R.
The purpose of the SSS is to provide the Project Team with a specification of the requirements of
eVACS® upgraded. The two parts of the SSS wil form the basis for developing a set of Software
Requirements Specification (SRS) and Interface Requirements Specification (IRS) documents.
1.2 Document overview
The upgraded eVACS® is based on eVACS® version 7.0 used by EACT in 2016 together with a number
of changed or additional requirements to be incorporated for the 2020 Election. The combined
requirements are described in Section 3, together with definitions of terms used in association with the
requirements. Itemised listings of the definitions and requirements can be found in Tables 1 and 2
respectively.
1.2.1 Definitions, requirements and actions
In section 3, definitions and requirements are interspersed with explanatory text. The content of
definitions and requirements is easily identifiable, as each begins with a heading in boldface and
includes a unique identifier with the following forms:
Applicable
Identifier
Definition of identifier elements
For definitions:
SSS-D-C-N
SSS = System Specification,
D = Definition,
C = Major Section within this document, i.e. 3, and
N = a sequential number commencing with 1
For requirements SSS-R-C.X-Y
SSS = System Specification,
R = Requirement,
C = Major Section within this document, i.e. 3,
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 8
C.X = a number being a subsection of section 3, where X is a
the subsection identifier, and
Y = a sequential number, commencing with 1, within C.X
This document is classified as Commercial-in-Confidence.
1.3 Reference Documents
In this SSS-1-R, a citation of the form [1] is a reference to document 1 in the fol owing list.
1. Business Requirements Specification ICT Business system upgrade - eVACS®, version 1.0;
2. Statement of Requirements at Schedule 2 of the Contract Electronic Voting and Counting System
(eVACS®) Enhancements, Services and Support: ACTGS reference 636238 Final Version 23 July
2019, being a simplified version of [1];
3. Software Improvements Pty Ltd, eVACS® Operational Concept Description, version 1.1, 2020;
4. The Unicode Consortium. Unicode Home Page available at https://unicode.org/main.html;
5. The Unicode Consortium. The Unicode Standard, Version 12.1 available at
http://www.unicode.org/versions/Unicode12.1.0/;
6. Software Improvements Pty Ltd, eVACS® System Specification - Part 2 Scenario Analyses, version
1.1, 2020
7. Contract Change Proposals 1 to 9
7.1
CCP1 – audio files to be WAV format
7.2
Incorporated into 7.3
7.3
Voting sequence to al ow for Hide My Vote from ballot screen and same voting sequence
for touchscreen and keypad operation
7.4
Use password protect USBs for transfer of data
7.5
Export of Pubic Key to support encryption of OSEV votes
7.6
Al ow multiple export of used voting tokens on a daily basis
7.7
Include support for new keypads
7.8
Include means to identify if drive has failed and secure means to replace failed drive
7.9
Modifications to format of e-voting cards and pol ing place Administrator cards
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 9
2 Acronyms
Abbreviation or Term
Meaning
ACT
Australian Electoral Commission
ACT EC
ACT Electoral Commission
ASD
Australian Signals Directorate
CJB
Carol Boughton
CRS
Counting and Reporting Server
CSV
Comma-separated values
CVB
Clive Boughton
DEC
Data Entry Client
DEO
Data Entry Operator
DES
Data Entry Server
DESuper
Data Entry Supervisor
EACT
Elections ACT
eVACS / eVACS®
electronic Voting and Counting System
I-ESS-EC
Interface for Election Setup Server
I-VC-VS
Interface between Voting Client and Voting Server
IRS
Interface Requirements Specification
IVR
Interactive Voice Response
LAPPERDS
Legislative Assembly Polling Place and Election Results Display System
OCD
Operational Concept Description
OSEV
Overseas Electronic Voting
PPO
Polling Place Official
RAM
Random-Access Memory
RB
Russell Baird
SIPL
Software Improvements Pty Ltd
SRS
Software requirements Specification
SSS
System Specification
SSS-1-R
System Specification – Part 1 Requirements
SSS-2-SA
System Specification – Part 2 Scenario Analyses
TSV
Tab-Separated Values
TVS
Telephone Voting Server
UI
User Interface
USB
Universal Serial Bus
USB-FD
USB Flash Drive
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 10
3 Requirements
3.1 Introduction
eVACS® Upgraded is to be based on the functionality provided for the 2016 ACT Legislative Assembly
election together with additional enhancements as reflected in new requirements.( [1], [2] and [7]). The
requirements for eVACS® Upgraded are therefore a combination of existing and new requirements.
The combined requirements are described in this Section 3, together with definitions of terms used in
association with the requirements. A list of definitions with their page locations is at Table 1 and a list
of the requirements with their page locations is at Table 2.
Section 3 has the following subsections:
Capability requirements
External interface requirements
Internal interface requirements
Internal data requirements
Safety requirements
Security and privacy requirements
Computer resource requirements
Design and construction constraints
Qualification provisions
3.2 System capability requirements
3.2.1 Overview of components
An installation of eVACS® to be used by Elections ACT for the 2020 Legislative Assembly Election
includes the fol owing software components:
• Election server, includes setup, data entry, counting and reporting functionality (one instance)
• Electronic voting client (many instances per polling place)
• Electronic voting server (one instance per pol ing place)
• Electronic telephone voting server (one instance)
• Interactive Voice Response platform for telephone voting (two instances)
• Data entry (many instances)
Except for telephone voting, all other software components are deployed individual y; only one can ever
be installed on any particular hardware at a time. For telephone voting, the inputs provided via a digital
telephone are to be transferred via ‘voting client’ software to the telephone voting server, in the same
manner as keystrokes are conveyed via the voting client to the voting server at pol ing places.
Note: Instal ing any of the eVACS® software components wil delete any and al software existing on
the hardware.
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 13
SSS-R-3.2-35
Ability to vary font size within candidate name
25
SSS-R-3.2-36
Provide flexibility in how text is programmed and displayed on
25
screen
SSS-R-3.2-37
Provide for touch screen functionality
25
SSS-R-3.2-38
Screen display colours
25
SSS-R-3.2-39
Welcome screen properties: select language
26
SSS-R-3.2-40
Welcome screen properties: messages
26
SSS-R-3.2-41
Welcome screen properties: e-voting card instruction
26
SSS-R-3.2-42
Main voting screen
26
SSS-R-3.2-43
Main voting screen properties: language
26
SSS-R-3.2-44
Main voting screen properties: groups
26
SSS-R-3.2-45
Main voting screen properties: candidates
26
SSS-R-3.2-46
Main voting screen properties: display
26
SSS-R-3.2-47
Main voting screen properties: Zoom and scroll
26
SSS-R-3.2-48
Main voting screen properties: Robson Rotation
26
SSS-R-3.2-49
Main voting screen properties: none
27
SSS-R-3.2-50
Main voting screen properties: preferences
27
SSS-R-3.2-51
Main voting screen properties: hide my vote
27
SSS-R-3.2-52
Confirmation screen
27
SSS-R-3.2-53
Confirmation screen properties: language
27
SSS-R-3.2-54
Confirmation screen properties: current voter
27
SSS-R-3.2-55
Confirmation screen properties: order
27
SSS-R-3.2-56
Confirmation screen properties: instruction
27
SSS-R-3.2-57
Confirmation screen properties: HIDE MY VOTE
27
SSS-R-3.2-58
Confirmation screen properties: empty
27
SSS-R-3.2-59
Reconfirm & scan screen
28
SSS-R-3.2-60
Hidden vote screen
28
SSS-R-3.2-61
Hidden vote screen properties: language
28
SSS-R-3.2-62
Hidden vote screen properties: message
28
SSS-R-3.2-63
Start again screen
28
SSS-R-3.2-64
Start again screen properties: language
28
SSS-R-3.2-65
Start again screen properties: message
28
SSS-R-3.2-66
Acknowledgement screen
28
SSS-R-3.2-67
Acknowledgement screen properties: language
28
SSS-R-3.2-68
Acknowledgement screen properties: message
29
SSS-R-3.2-69
Acknowledgement screen properties: colour
29
SSS-R-3.2-70
Reset
29
SSS-R-3.2-71
Voting server initial menu
29
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 14
SSS-R-3.2-72
Voting server menu during voting
30
SSS-R-3.2-73
Make two backups of voting server
20
SSS-R-3.2-74
Verifying voting server backups
30
SSS-R-3.2-75
Errors during writing backup of voting server
30
SSS-R-3.2-76
Generate and print QR codes for each voting server backup
30
SSS-R-3.2-77
Telephone voting server initial menu
30
SSS-R-3.2-78
Telephone voting server menu during voting
30
SSS-R-3.2-79
Make two backups of telephone voting server
31
SSS-R-3.2-80
Verifying telephone voting server backups
31
SSS-R-3.2-81
Errors during writing backup of telephone voting server
31
SSS-R-3.2-82
Data entry and counting servers installed
31
SSS-R-3.2-83
Data entry login screen
32
SSS-R-3.2-84
Vote entry screen
32
SSS-R-3.2-85
End vote screen
32
SSS-R-3.2-86
Cancel vote screen
32
SSS-R-3.2-87
Log data entry
33
SSS-R-3.2-88
Paper bal ot entry client response time
33
SSS-R-3.2-89
Data entry correction and batch control menu
33
SSS-R-3.2-90
Vote control screen
34
SSS-R-3.2-91
End vote control screen
34
SSS-R-3.2-92
Cancel vote control screen
34
SSS-R-3.2-93
Integrate polling place votes
34
SSS-R-3.2-94
Integrate data entry votes
34
SSS-R-3.2-95
Export votes from data entry
34
SSS-R-3.2-96
Tag exported votes
34
SSS-R-3.2-97
Counting data backups
34
SSS-R-3.2-98
Counting audit
34
SSS-R-3.2-99
Intermediate results
34
SSS-R-3.2-100
Hare-Clark algorithm
35
SSS-R-3.2-101
Hare-Clark counting to provide for two counting options
35
SSS-R-3.2-102
Count by count scrutiny sheets
35
SSS-R-3.2-103
Counting of the choices
35
SSS-R-3.2-104
Distribution of effective votes
35
SSS-R-3.2-105
Tracking preferences
35
SSS-R-3.2-106
Counting - Less than 20 rule
35
SSS-R-3.4-1
Unicode
37
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 15
SSS-R-3.6-1
Voter anonymity
38
SSS-R-3.6-2
No public network
38
SSS-R-3.6-3
Vote data integrity and security
38
SSS-R-3.6-4
Access passwords to conform to Government requirements
38
SSS-R-3.6-5
ASD approved cryptographic protocols
38
SSS-R-3.6-6
Limit availability of ports on hardware
38
SSS-R-3.6-7
Hash code to be used when uploading votes to election server
38
SSS-R-3.7-1
Hardware supported by operating system
39
SSS-R-3.7-2
Election setup hardware
39
SSS-R-3.7-3
Electronic voting client hardware
39
SSS-R-3.7-4
With use of USB-FDs no longer applicable[
41
SSS-R-3.7-5
Operating system
41
SSS-R-3.7-6
Language of software shal be Ada
41
SSS-R-3.8-1
Independent code audit
41
SSS-R-3.8-2
Enhancements and legislative changes
41
SSS-R-3.9-1
Use of non-volatile storage on clients
41
SSS-R-3.10-1
Support for tests by officials
42
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 16
3.2.2 Election terminology
This section contains only definitions.
For an ACT Legislative Assembly Election currently there are five electorates each with a different bal ot
paper containing candidates representing different registered parties or independents, with five
members to be elected for each electorate. The following definitions are those required to ensure
accuracy in the development of an electronic voting, including telephone voting, eVACS® solution for
ACT elections.
3.2.2.1 Elections
Definition SSS-D-3-1: Election
An election is a set of related contests. An election has the following properties:
Name: The name of the election.
Date:
The date of the election.
Bal ot type: See definition SSS-D-3-12
Rotation type: See definition SSS-D-3-13
Bal ot instructions: Instructions on how to fil out an electronic ballot
Choice presentation: The format to be used for presenting candidate choices when displaying or
describing a bal ot.
Electorate type: The term used for an electorate in an election. In ACT Legislative Assembly elections
‘electorate’ is used; compare ‘divisions’ used in Federal House of Representative elections.
Contests: A set of contests
Definition SSS-D-3-2:Contest
A contest is a decision to be made by the voters associated with a particular electorate. A contest is a
selection of candidates, currently five. Each contest has the fol owing properties in addition to those
associated with the ballot type (see definition SSS-D-3-12), the rotation type (see definition SSS-D-3-
13), and the counting system (see definition SSS-D-3-18).
Electorate: The name of the electorate in which the contest is to be held.
Parties: A list of registered parties fielding candidates in the electorate.
Groups: A list of groups (either parties or independents listed in the same column on the ballot).
Choices: A list of contest choices (see definition SSS-D-3-3) for voters to select from.
In other words, an election specifies a number of contests – one per electorate – and the parameters
common to all those contests.
In the ACT candidates not affiliated with a party are grouped into one or more groups label ed
“Ungrouped”.
Definition SSS-D-3-3: Contest choice
A contest choice is a choice between candidates.
Definition SSS-D-3-4:Candidate Choice
A candidate choice is a person standing in a contest. Each candidate choice has the fol owing
properties:
Name: The name of the candidate
Party: The party to which the candidate belongs, if any
Group: The group to which the candidate is to appear on the ballot
Position: The canonical position within the group in which the candidate is to appear on the bal ot
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 17
The Position property refers to ‘canonical’ position within the group.. However, the actual position used
in the presentation of a particular bal ot also depends on the rotation type (
SSS-D-3-13) associated with
the election.
Definition SSS-D-3-5: Voter
A voter is a person who casts a vote in a contest.
Eligibility to vote in a particular contest is beyond the scope of eVACS®.
3.2.2.2 Bal ots and Votes
A ballot is the means by which a voter casts a vote in a contest. In eVACS®, there are two types of
ballots: paper and electronic.
Definition SSS-D-3-6: Ballot
A bal ot is either a paper bal ot or an electronic bal ot.
Definition SSS-D-3-7: Paper Ballot
A paper ballot is a piece of paper which can be used by a voter to make a vote in a contest.
Definition SSS-D-3-8: Electronic Bal ot
An electronic ballot is a presentation by the eVACS® voting client software of an interface by which a
voter can make a vote in a contest.
There are two types of electronic ballot: screen presentation with or without audio, and audio alone.
Definition SSS-D-3-9: Vote
A vote is either a paper vote or an electronic vote.
Definition SSS-D-3-10: Paper vote
A paper vote is the data generated by:
1. the eVACS® data entry client software as a result of a data entry operator entering the contents
of a ballot paper, or
2. external software scanning a paper ballot.
Definition SSS-D-3-11: Electronic vote
An electronic vote is the data generated by the eVACS® voting client software as a result of a voter
fil ing in an electronic bal ot.
A vote completed as a result of a voter selecting keys on a telephone keypad or digital telephone in
accordance with audio instructions is considered an electronic vote.
A vote completed via the Overseas Electronic Voting system is considered and electronic vote when
uploaded to eVACS®,
3.2.2.3 Ballot type, vote formality, and interpretations and Votes
eVACS® must determine the formality of each vote so that only formal votes can be counted. It must
also determine how a formal vote is to be interpreted during a count.
Definition SSS-D-3-12: Bal ot type
Ballots for the ACT Legislative Assembly are of
Ranked Preference type.
A number of candidates are to be marked with consecutive integers beginning with 1 (most preferred).
Minimum: The minimum number of candidates which must be marked for the electronic vote to be
formal in the ACT is one (1).
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 18
Maximum: There is no maximum specified for the ACT.
Last preference implied: If there is only one candidate left on the ballot without a preference, then the
last candidate is assumed to have received the last preference. Last preference implied is not used in
the ACT.
3.2.2.4 Bal ot rotation
In the ACT the ordering of contest options varies from bal ot to bal ot. This is referred to as Robson
Rotation.
Definition SSS-D-3-13: Rotation by permutation sequence
Rotation of contest choices is performed with the use of a sequence of permutations.
Permutation sequence: A sequence of permutations in which the order of candidates are displayed
within a group.
In the ACT with five members to be elected per electorate, the total number of Robson Rotation
permutations is 60.
In general, parties usually field the maximum of five candidates; however, some parties and
independents may have less than five in their group. In this case a reduced permutation is adopted.
Should a party nominate more than 5 candidates, the candidates are spread as evenly as possible
across multiple columns and the permutations apply separately to each column.
A mathematical description of permutations applicable to variable numbers is provided at Appendix A.
3.2.2.5 Polling places
Definition SSS-D-3-14: Polling place
A polling place is a location where voters may cast a vote in at least one contest; for the ACT Legislative
Assembly Election a voter can only cast a vote in one contest. Each polling place has the following
associated property:
Name: The name of the polling place.
As part of the process of setting up an election, polling places are defined, and sets of barcodes are
generated for each pol ing place. Each barcode al ows the casting of an electronic vote in a contest.
For telephone voting a single electronic polling place is established and instead of a barcode voters use
a predetermined password/voting token combination to cast their vote.
The OSEV system is also identified as a single electronic pol ing place.
3.2.2.6 Vote interpretation
Once a vote has been entered it must be checked against the formality rules for the contest. If it is
formal, it must also be normalised to make it suitable for counting.
Definition SSS-D-3-15: Vote normalisation
Vote normalisation is the process applied to a vote to transform it into a form which can be counted
using the counting process for the contest.
Definition SSS-D-3-16: Unnormalised and normalised vote
Each vote cast in a contest exists in two forms: unnormalised and normalised. The unnormalised form
contains the voter’s indications as expressed on the ballot; the normalised form is the result obtained
by applying the vote normalisation process for the contest.
In the ACT a paper vote is accepted as formal as long as it contains a unique first preference, even
though it may contain gaps in the numbering sequence or preferences which are duplicated. For
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 19
example, a paper vote containing the preferences 1, 2, 3, 4, 4, 5, 6 in the normalisation process would
keep the first three preferences and discard the rest.
Definition SSS-D-3-17: Normalisation process
A normalisation process is one of the fol owing:
No normalisation - al vote preferences are left as is
Add last preference - last preference is inferred (not used in the ACT)
Remove gaps and duplicates – al preference beyond a gap in preferences or from a duplicate in a
preference are removed, since the allocation of the next preference cannot be determined.
For example, if the preference sequence is: 1, 2, 3, 5, 6, then the candidate to receive the 4th preference
is unknown and therefore the next preference after 3 cannot be assigned. Similarly, if the preference
sequence is 1, 2, 3, 4, 4, 5, the next preference after 3 cannot be assigned.
3.2.2.7 Counting system
Definition SSS-D-3-18: Counting system
The counting system used for ACT Legislative Assembly elections is Hare-Clark (a type of electoral
system of proportional representation using ranked preference bal ots).
In an election using the Hare-Clark system, each contest has the fol owing associated property:
Seats: The number of winners to be declared in the contest. For ACT, this is the number of members
to be elected, currently five per contest (electorate).
3.2.3 Requirements on rotations
Requirement SSS-R-3.2-1: Bal ots with rotation by permutation sequence
eVACS® supports ACT Legislative Assembly elections that use rotation of contest choices by
permutation sequence.
Each voting server is responsible for issuing permutations to the voting clients that are connected to it.
Permutations are issued by making a selection from the appropriate permutation sequence, treating the
sequence as though it were a continuous loop.
Similarly, the telephone voting system is to provide the same functionality as a voting server at a pol ing
place.
Requirement SSS-R-3.2-2: Voting server to manage use of sequences
Upon receipt of a request for a permutation for a contest from a voting client, a voting server shall issue
the voting client with the permutation selected from the permutation sequence associated with that
contest.
Requirement SSS-R-3.2-3: Permutation used in sequence
When a voting server selects a permutation from a permutation sequence, the permutation shal be:
• The first permutation in the sequence, if no client has previously requested a permutation from
that sequence;
• The first permutation in the sequence, if the immediately preceding request for a permutation
from that sequence resulted in the selection of the last permutation in the sequence;
• That permutation in the sequence which immediately follows the permutation most recently
selected from that sequence, otherwise.
Requirement SSS-R-3.2-4: Permuted display of contest choices
When a voting client is required to display an electronic ballot which uses rotation by permutation
sequence, the voting client shall, if and only if it has not previously done so during the current voting
session, request the voting server to issue a permutation for the contest.
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 20
Requirement SSS-R-3.2-5: Displaying a contest choice within a group
When a voting client displays a contest choice as part of an electronic bal ot which uses rotation by
permutation sequence, the same rotation is used for the candidates within each group on the bal ot
paper.
For example, if the rotation order is 4, 3, 5, 2, 1 and there are 5 candidates standing, then for this bal ot
paper candidate 4 is in position 1, candidate 3 is in position 2, candidate 5 is in position 3, candidate 2
is in position 4 and candidate 1 is in position 5, where candidate numbering is based on their initial
position on the ballot as drawn by the Electoral Commissioner.
If instead there are only three candidates in a particular group, then the order of presentation of these
candidates based on the rotation order of 4, 3, 5, 2, 1 is candidate 3 in position1, candidate 2 in position
3, and candidate 1 in position 3.
Formally, the contest choice to be displayed shall be determined as follows with the above example to
illustrate:
1. Let
p be the permutation issued by the voting server for this contest for this voting session.[e.g.
4, 3, 5, 2, 1]
2. Let
c be the total number of contest choices in the group in which the contest choice is to be
displayed.[e.g. c = 3]
3. Let
i be the screen position in which a contest choice is to be displayed (where the first position
is 1 and the last is
c) [e.g. positions 1, 2, 3]
4. The contest choice to be displayed in position
i in the group is the contest choice of that group
which has its Position property equal to
p(i).
hence, if the permutation for a particular ballot has the order 4, 3, 5, 2, 1 and the number of contest
choices is only 3, then the order of presentation of the three candidates would be: 3 in position 1, 2 in
position 2, 1 in position 3.
3.2.4 General Requirements
3.2.4.1 Auditing
Requirement SSS-R-3.2-6: Electronic audit logs
Every software component of eVACS® shal have the capacity to add auditing data to an electronic log.
Because of the physical separation of the components of eVACS®, the audit log is a distributed log.
The fol owing definition allows reference to logging without giving an indication of the physical location
where a datum of audit information is stored.
Definition SSS-D-3-19: The audit log
The audit log is the col ection of electronic audits maintained by al of the components in an installation
of
eVACS®.
Definition SSS-R-3.2-7: Audit log entries timestamped
Whenever an entry is made in the audit log a timestamp of when an entry was made shall be included
in the entry, noting that committed votes are not to be time stamped.
Definition SSS-R-3.2-8: Audit log entries indicate origin
Whenever an entry is made in the audit log the entry shall identify the component of eVACS® which
generated the entry.
Definition SSS-R-3.2-9: Access to the audit log
There shal be a capability for an authorised election official to generate a report of al audit data for
each eVACS® component.
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 21
3.2.4.2 Errors and exceptions
Definition: SSS-D-3-20: Error
An error is any event or circumstance that prevents eVACS® from operating.
Definition: SSS-D-3-21: Error message
An error message is text that describes an error. Such text may be generic (i.e. Identical for each
possible occurrence of an error), or contain a generic component as well as data specific to a particular
occurrence of an error, as appropriate.
Definition: SSS-R-3.2-10: Display error message on error
When an error occurs eVACS® shall display an error message corresponding to that error.
Definition: SSS-R-3.2-11: Display error message only on error
eVACS® shal not display an error message unless an error has occurred.
Definition: SSS-R-3.2-12: Errors logged to audit log
When an error occurs a description of the error shall be added to the audit log.
Definition: SSS-R-3.2-13: Error messages with recovery instructions
An error message may either describe the steps to be taken to return eVACS® to operating condition,
or give an index number by which the steps to be taken may be found.
Definition: SSS-R-3.2-14: Error messages for voters and officials
When eVACS® requires a voter or election official to take some action to correct an error the required
steps shall be described in the error message.
When eVACS® requires a trained technician to take some action to correct an error, the error message
may give only an index number by which the steps to be taken may be found.
3.2.4.3 Languages other than English
Definition: SSS-D-3-22: Multiple languages
eVACS® shall support multiple languages, including English, in respect of al written instructions and
messages.
The particular languages available for a specific election is not pre-set, and is determined by Elections
ACT for each election.
Note: Currently audio is only provided in English.
Requirement: SSS-R-3.2-15: Use of localised language for display and printing
Unless explicitly specified to the contrary, where a requirement or action includes text intended for
display or printing, including instructions, that text shall be displayed or printed in a localised translation.
3.2.5 Election setup
Requirement: SSS-R-3.2-16: Instal ation erases disk contents
The process of instal ing the election setup server shal ensure that only software distributed as part of
the election server setup software is instal ed concurrently on the same hardware.
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 23
Requirement: SSS-R-3.2-23: One vote per PIN/Voting Token pair per contest
For any contest, the system shal not allow a PIN/Voting Token pair
to be used to confirm more than
one vote in the contest.
Requirement: SSS-R-3.2-24: Arrangement of candidates on an electronic bal ot
When displaying an electronic bal ot to a voter, the system shal display candidates in party groups as
a column followed by column or columns of candidates who are not members of a registered party.
Requirement: SSS-R-3.2-25: Ballot legibility
The voting client shal display electronic ballots according to legibility guidelines.
Requirement: SSS-R-3.2-26: Voting data stored twice
eVACS® shal ensure that two copies of the electronic voting data are stored in separate locations
within the polling place immediately after a vote is cast and confirmed by the voter.
Requirement: SSS-R-3.2-27: Voting data not to be stored with timestamp
eVACS® shal ensure that when a vote is stored in the votes database there shal be no timestamp
associated with that transaction.
Note: There wil stil be a timestamp associated with a barcode or PIN/voting token pair being
‘marked’ as used.
Requirement: SSS-R-3.2-28: Pre-pol ing backup
eVACS® shal be capable of providing at the end of each day of the pre-polling period, electronic
backup copies of voting data from each pre-pol ing centre.
Requirement: SSS-R-3.2-29: Spoken instructions
The electronic voting interface shall incorporate spoken instructions in English broadcast over
disposable headphones for sight impaired people and for people with reading difficulties.
The telephone voting interface shall incorporate spoken instructions in English.
Requirement: SSS-R-3.2-30: Al formal votes accepted
The voting client (for polling place and telephone voting) shall support the entering of any vote that is
considered formal.
Requirement: SSS-R-3.2-31: Informal votes
The voting client (for polling place and telephone voting) shall support the entering of informal votes, in
which no candidate has been selected.
Requirement: SSS-R-3.2-32: Voting client response time
After a vote is confirmed, eVACS® shall display the acceptance screen in a different colour for a
specified time to be set the Elections ACT(subsequently set at 15 seconds). After that time expires,
eVACS® shal be ready for the next voter within one second.
3.2.6.1 Barcodes
Requirement: SSS-R-3.2-33: Barcodes to be QR codes
2D barcodes, i.e. QR codes, are to be used for accessing voting terminals and casting votes, referred
to as e-voting barcodes (that wil be printed on e-voting cards).
A Master Admin QR code is to be required per polling place for use by a polling official to reset and
shutdown voting terminals (instead of the previous key press sequences) and to access the menu
functions on the pol ing place and telephone voting servers. Two copies to be printed, with one being
a backup. One other Master Admin QR code is required to access the Election server.
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 27
Requirement: SSS-R-3.2-49: Main voting screen properties: none
The ‘Main Voting Screen’ shall display each candidate name with an empty box to the left when no
preferences have been entered.
Requirement: SSS-R-3.2-50: Main voting screen properties: preferences
If a vote contains a preference for a candidate, the ‘Main Voting Screen’ shal replace the empty box to
the left of the candidate name with a coloured box containing the preference number for that candidate.
For touch screen preferences, the preference box or name of candidate shall be selectable by a single
touch.
Requirement: SSS-R-3.2-51: Main voting screen properties: hide my vote
The ‘Main Voting Screen’ shall provide for the voter to ‘hide their vote’ with a message displayed and
played to “Raise hand for help’.
3.2.6.4.4
Confirmation Screens
3.2.6.4.4.1 Confirmation screen with choices
Requirement: SSS-R-3.2-52: Confirmation screen
The ‘Confirmation Screen’ shall al ow the voter to view and return to Main Voting screen to modify the
current vote before concluding the voting session.
Requirement: SSS-R-3.2-53: Confirmation screen properties: language
The ‘Confirmation Screen’ shall display or play instructions in voter’s preferred language.
Requirement: SSS-R-3.2-54: Confirmation screen properties: current vote
If the current vote is not empty, the ‘Confirmation Screen’ shal display and play only and al the
candidates in the current vote, with the message such as ‘Your choices in preference order are:’
Requirement: SSS-R-3.2-55: Confirmation screen properties: order
The ‘Confirmation Screen’ shall display those candidates in ascending order of the preference numbers
in the boxes which were to their left on the ‘Main Voting Screen’.
Requirement: SSS-R-3.2-56: Confirmation screen properties: instruction
If the current vote is not empty, the ‘Confirmation Screen’ shal display the instruction: “Review your
choices “ fol owed by ‘To change your choices touch GO BACK. OR To confirm your choices scan your
e-voting card.’
If the current vote is not empty the audio shal refer to UNDO to go back and to scan e-voting card (or
enter PIN for telephone voting) to confirm preferences.
Requirement: SSS-R-3.2-57: Confirmation screen properties: hide my vote
The ‘Confirmation Screen’ shall provide for the voter to ‘hide their vote’ with a message displayed and
played to “Raise hand for help’.
3.2.6.4.4.2 Confirmation screen with no choices (Informal vote screen)
Requirement: SSS-R-3.2-58: Confirmation screen properties: empty
If the current vote is empty, the ‘Informal Vote Screen’ shall be displayed with messages and audio such
as ‘You have not selected any candidates. Do you want to cast a blank informal vote/” with the choices:
No I want to return to the ballot paper. Touch GO BACK or press SELECT (5) to continue selecting
candidates
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 28
Yes I want to cast a blank informal vote. Touch CAST AN INFORMAL VOTE or press FINISH (#) to
continue.
3.2.6.4.4.3 Reconfirm and scan screen with no choices
Requirement: SSS-R-3.1-59: Reconfirm & scan screen properties: instruction
If CAST AN INFORMAL VOTE is selected on the Informal Vote screen, the ‘Reconfirm & Scan Screen
shall be displayed with:
Nearly there …
Scan your e-voting card now to cast your informal vote
OR
To return to the ballot paper, touch GO BACK
Audio instructions refer to pressing UNDO (*) to go back or scan e-voting card to cast vote (or enter PIN
for telephone voting).
3.2.6.4.5
Hidden Vote Screen
Requirement: SSS-R-3.2-60: Hidden vote screen
The ‘Hidden Vote Screen’ shall hide the voter’s current vote.
Requirement: SSS-R-3.2-61: Hidden vote screen properties: language
The ‘Hidden Vote Screen’ shall display instructions in the voter’s preferred language.
Requirement: SSS-R-3.2-62: Hidden vote screen properties: message
The ‘Hidden Vote Screen’ shall display the message; “Your vote is now hidden. Raise your hand if you
need help. An e-voting officer wil be with you shortly”
With the option to CONTINUE VOTING if voter arrived at Hidden Vote screen from Main Voting screen.
With options to CONTINUE VOTING or scan e-voting card if voter arrived at Hidden Vote screen from
Confirmation screen.
3.2.6.4.6
Start Again Screen (Clear Choices screen)
Requirement: SSS-R-3.2-63: Start again screen
The ‘Start Again Screen’ shall al ow the voter the option to clear the Vote-in-Progress and enter a new
set of preferences.
Requirement: SSS-R-3.2-64: Start again screen properties: language
The ‘Start Again Screen’ wil be displayed in the voter’s preferred language.
Requirement: SSS-R-3.2-65: Start again screen properties: message
The ‘Start Again Screen’ wil display and/or play the question “Are you sure you want to clear all
preferences and start again? With the choice of Yes or No.
3.2.6.4.7
Acknowledgement Screen (Acceptance screen)
Requirement: SSS-R-3.2-66: Acknowledgement screen
The ‘Acknowledgement Screen’ shal appear on conclusion of the voting session.
Requirement: SSS-R-3.2-67: Acknowledgement screen properties: language
The ‘Acknowledgement Screen’ message wil be in the voter’s preferred language.
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 38
Each voting server, polling place and telephone voting, exports vote data to USB-FDs as part of backup
processes; these must be delivered securely to the location of the counting server.
The fol owing list summarises the required security policies.
Barcode data generated from setup process
• Secure transport between setup and printing facility
• No barcode data retained at printing facility
Printed barcodes
• Secure transport between printing facility and election officials
• Secure delivery to, and storage at, electronic voting centres
• No barcode issued to a voter unless and until eligibility to vote has been confirmed
USB-FDs containing backups of voting server, polling place and telephone voting
• Use of encrypted container on USB-FDs used for transferring votes
• Secure delivery to and from voting server
Voting tokens generated from setup process
• Use of encrypted container on UDB-FD for secure transfer to system assigning tokens
• Voting tokens randomly assigned to registered telephone voters on electorate basis
USB-FDs containing PIN/voting token pairs
• Secure delivery to telephone voting server
Requirement SSS-R-3.6-1: Voter anonymity
The system shal protect the anonymity of each voter, including the shuffling of votes in the database.
Requirement SSS-R-3.6-2: No public network
The system shall not be connected to any outside network in any of the electronically equipped pol ing
places, and the central scrutiny centre.
Requirement SSS-R-3.6-3: Vote data integrity and security
The system shall al ow for votes data to be transferred to the vote counting system without accidental y
or deliberately being altered.
Requirement SSS-R-3.6-4: Access passwords to conform to Government requirements
Passwords throughout the system should only be able to be set if they meet ACT Government and ASD
password security standards.
Requirement SSS-R-3.6-5: ASD approved cryptographic protocols
Only ASD approved cryptographic protocols to be used throughout the system, I.e. TLS1.2 and SHA2.
Requirement SSS-R-3.6-6: Limit availability of ports on hardware
Al unused ports on server and client components shal be decommissioned via the operating system.
3.6.1 Requirement to be satisfied by a system component
Requirement SSS-R-3.6-7: Hash code to be used when uploading votes to election server
To import data from the voting servers into the election server, the system is to mandate the entry of the
hash code (in QR code format) on the election server.
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 39
3.7 Computer resource requirements
The descriptions provided in this section serve as a base definition of support for the operation of
eVACS®. Each requirement referring to a particular item of hardware or software is more properly
interpreted as a constraint on the design of eVACS®.
3.7.1 Hardware requirements
The components of eVACS® are designed to operate on off-the-shelf hardware. Except where
otherwise specified, the following specifications are to be regarded as minimums. In addition, only
components support by the required operating system are to be used (see SSS-R-3.7-5)
Requirement SSS-R-3.7-1 Hardware supported by operating system
Where a hardware component is listed as a requirement, that hardware component shal also be
supported by the required operating system.
3.7.1.1 Election servers
Requirement SSS-R-3.7-2 Election setup - hardware for servers
The election server hardware shall at a minimum consist of the fol owing:
• Intel architecture i5/i7
• 8 GB main memory
• PC-type keyboard
• 256 GB hard disk drive
• USB ports (at least three for keyboard, scanner and printer)
• Ethernet card 802.3
Plus
• USB connected PCL Printer for A3 printing
• Screen appropriate to view menu and preview ballot (1920 x 1080 resolution)
For polling place server or telephone voting server, same as for election server with the following
changes:
• 16 GB instead of 8 GB main memory
• Additional 256 GB hard disk drive
• 2D barcode reader (scanner)
• PCL printer for A4 printing
• Screen to view menus
3.7.1.2 Electronic ‘clients’
Requirement SSS-R-3.7-3 Electronic voting client hardware
The electronic voting client hardware shall consist of the fol owing:
• Intel architecture i5
• 4 GB main memory
• USB port (for scanner)
• Ethernet 802.3
If a client is to support touchscreen functionality, it shal also consist of:
• 23” touch screen display supporting 1920 x 1080 resolution and single touch
• A scanner
Note: voting client is expected to be an Al -in-One
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 41
Data entry client
Same as for voting client
The functionality of the keypad (standard keyboard with numeric keypad with NUM LOCK On) used for
data entry is as shown in Figure 4.
FINISH CANCEL
7
8
9
NEXT
GROUP
4
5
6
1
2
3
0
DELETE
/
YES
NO
Figure 4 - Key pad for data entry
Vote storage
Officials must ensure cleansed, and if available write once, media is used for transporting and storing
vote data.
Requirement SSS-R-3.7-4 Voter data media finalised
Requirement applied to use of CD/DVD and is not applicable to USB-FDs.
Computer software requirements
Requirement SSS-R-3.7-5 operating system
Each of the computers to be used for eVACS® shal be capable of operating with the Linux operating
system.
Requirement SSS-R-3.7-6 Language of software to be Ada
eVACS® upgraded shall be written in Ada, current version being Ada 2012.
3.8 System quality factors
Requirement SSS-R-3.8-1 Independent code audit
The system shal allow programming code to be independently audited and be available to scrutineers
for verification.
Requirement SSS-R-3.8-2 Enhancements and legislative changes
The system shal be capable of amendment to cater for enhancement and legislative changes.
3.9 Design and construction constraints
3.9.1 Voting client
Requirement SSS-R-3.9-1 Use of non-volatile storage on voting client
The voting client shal not store electorate, candidate, or vote data in its non-volatile storage.
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 42
This constraint nevertheless permits a voting client to cache such data in its non-volatile storage (i.e.,
in RAM)
3.9.2 Training related requirements
Al training and development of training materials is undertaken by EACT officials.
3.9.3 Logistic related requirement
As rotation of bal ot papers is used in ACT Legislative Assembly Elections, every paper bal ot for that
election must have a rotation number printed on it; this rotation number is entered before data entry of
the ballot details as part of the data entry process.
3.10 Qualifications provisions
Requirement SSS-R-3.10-1 Support for tests by officials
The system shall be capable of being tested by EACT officials under load conditions to the satisfaction
of officials prior to acceptance of the system.
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 43
4 Requirements traceability
A separate matrix traces requirements through the various development documents.
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
System Specification – Part 1 Requirements
Page 44
Appendix A - Permutation explanations
Permutation
In general terms a permutation is one of several possible ways in which a set of numbers or things can
be ordered or arranged.
For example, if there are three numbers 1, 2 and 3, then these can be arranged in order to give 6
possible permutations:
1 2 3, 1 3 2, 2 1 3, 2 3 1, 3 1 2, and 3 2 1
This can be expressed mathematical y as follows.
A permutation of the numbers 1 …
n is a function
p : { 1
,..., n} → { 1
,..., n} which is a bijection*.
For example, the function { 1 I → 3
, 2 I → 5
, 3 I → 4
, 4 I → 2
, 5 I → 1
} is a permutation of the numbers 1
n, where
n = 5, but the function { 1 I → 3
, 2 I → 5
, 3 I → 4
, 4 I → 3
, 5 I → 1} is not because although the
numbers 1 to 5 are part of the first set, the mapped set does not correspond, having 1, 3, 3, 4, 5 instead.
*Bijection is a ‘mapping’ that is both one-to-one (an injection) and onto (a surjection), i.e. a function which relates
each member of a set
S (the domain) to a separate and distinct member of another set
T (the range), where each
member in
T also has a corresponding member in
S.
Size of Permutation
If
p is a permutation of the numbers 1…
n, the size of
p , denoted by size(
p), is
n.
If an election uses rotation by permutation sequence, displaying an electronic ballot involves arranging
the contest choices in each group in an order determined by a permutation selected from the
permutation sequences for the contest.
Because the number of contest choices in a group may not be equal to the size of the permutation, the
choices are arranged using a reduced permutation.
Given a permutation
p and a number
c which is less than or equal to the size of
p, the reduced
permutation of
p to size
c, denoted
pc , is the permutation of the numbers 1…
c calculated according to
the following algorithm:
1. Set
i → 1 and
j → 1
2. Set
pc → { }
3. While
i ≤ size(
p):
3.1. If
p(
i) ≤
c then:
3.1.1. Set
pc →
pc → {
j I →
p(
i)}
3.1.2. Set
j →
j + 1
3.2. Set
i →
i + 1
For example, if
p = { 1 I → 3
, 2 I → 5
, 3 I → 4
, 4 I → 2
, 5 I → 1} , then:
p5 = { 1 I → 3
, 2 I → 5
, 3 I → 4
, 4 I → 2
, 5 I → 1}
p4 = { 1 I → 3
, 2 I → 4
, 3 I → 2
, 4 I → 1}
p3 = { 1 I → 3
, 2 I → 2
, 3 I → 1}
Commercial-in-Confidence
Software Improvements Pty Ltd © 2020
