|
As
noted, the VVSG is intended primarily for voting system manufacturers
and test lab personnel. However, the language used throughout
has been improved and made more understandable for most audiences.
This section contains a brief overview of how to read the document
and best understand its features and requirements.
The
first place to start in understanding the VVSG is to understand
how language is used. The language is divided into two categories:
normative, i.e., the requirements language itself, and
informative. Informative parts of the VVSG include discussion,
examples, extended explanations, and other matter that is necessary
for proper understanding of the requirements and conformance to
them. Informative text may serve to clarify requirements, but
it is not otherwise applicable.
Normative language is specifically for requirements. The following
keywords are used within requirements text to indicate the conformance
aspects of the requirement:
- Shall
indicates a mandatory requirement to do something;
- Is
prohibited indicates a mandatory requirement not
to do something;
- Should,
Is encouraged indicate an optional recommended
action;
- May
indicates an optional, permissible action.
The requirements are structured specifically to make them more
clear and precise. Requirements may have subrequirements, usually
used when the main requirement needs further definition of its
implications. A typical requirement and subrequirement is as
follows:
|
|
3.3.3-C
Audio Features and Characteristics
voting
stations that provide audio presentation of the
ballot shall do so in a usable way, as detailed in the following
subrequirements.
Applies
to: VEBD-A
Test
Reference: Part 3 Section 3.2
DISCUSSION
These requirements apply to all voting system audio output,
not just to the ATI
of an accessible
voting station.
|
|
|
3.3.3-C.1
Standard Connector
The ATI
SHALL provide its audio signal through
an industry standard connector for private listening using
a 3.5mm stereo headphone jack to allow voters to use their
own audio assistive devices.
Applies
to: VEBD-A
Test
Reference: Part 3 Section 3.2
|
Requirements
and their subrequirements are designated by the " "
and " "
characters, respectively. Requirements are numbered according
to the section of the VVSG they appear in; the titles serve as
a shorthand description. The actual text of a requirement appears
directly below the requirement in blue. Requirements have the
following fields:
- Applies
to: indicates which voting system or device class the requirement
applies to (see the discussion of classes in the following section);
- Test
Reference: what type of testing must be used for testing
whether the requirement is met; these point to appropriate sections
in Part 3: Testing Requirements;
- Description:
optional: informative supporting information for the requirement;
- Reference:
optional: the source for the requirement; many requirements
are new.
Each
usage of a word or term with special meaning in the VVSG is linked
to its definition in Appendix A: Definitions
of Words with Special Meaning in the VVSG.
With
some background on requirements structure and language, readers
should then read the Conformance Clause chapter 2 of Part 1: Equipment
Requirements. The conformance clause contains information relating
to conformance to the VVSG and provides further explanations of
how to interpret requirements language.
The
conformance clause also defines classes. The purpose
of classes is to categorize requirements into related groups of
functionality that apply to different types of voting systems
and devices. Understanding how classes work is the key for understanding
requirements and their implications.
There
are two types of classes:
- Voting
system classes: each class pertains to a voting system
that supports a specific voting
variation, e.g., primary
elections, open
primaries, straight
party voting, etc.
- Voting
device classes: each class pertains to a voting device,
ranging from higher-level classes such as vote-capture
device to lower-level, specific classes that describe
specific devices such as VVPAT
or PCOS.
Most
requirements have an Applies to: field that contains
the name of a class or several classes that the requirement essentially
applies to, e.g., a requirement dealing with cryptography with
Applies to: Vote-capture
device, means that all vote-capture
devices must satisfy the requirement. The vast majority
of requirements in the VVSG apply to device classes, i.e., types
of voting devices.
As
stated previously, classes may subsume (or incorporate) other
subclasses below them in the hierarchy. For example, vote-capture
device subsumes IVVR
vote-capture device, which subsumes other subclasses beneath
it. The subsuming class is called the superclass, while the subsumed
classes are called subclasses.
Figure
1: Class inheritance
Subclasses
inherit the requirements of their superclasses, e.g., in the class
diagram in Figure 1, the lines that connect the classes show that
EPB inherits all requirements that apply to EBM,
which inherits all requirements that apply to IVVR
vote-capture device, which inherits all requirements that
apply to Vote-capture
device. A subclass may add new requirements, e.g., IVVR
vote-capture device contains requirements in addition
to those that apply to Vote-capture
device and so forth. However, a subclass is not allowed
to relax or remove requirements inherited from a superclass; everything
that applies to Vote-capture
device, for example, applies also to every subclass of
Vote-capture
device.
The
lines that connect the classes in class diagrams are there to
show the hierarchical inheritance relationships among the classes.
However, there are voting devices that may be special-purpose
and that are not represented by a specific device class or lines.
These sorts of voting devices can belong to (or inherit the requirements
of) multiple classes at the same time. For example, the complete
device classes diagram in Part 1 Chapter 2 does not show a device
class for an accessible VVPAT,
yet it is possible to have such a device. The way in which this
is identified is actually in the requirements that would apply
to such a device. For example, a requirement that applies to a
VVPAT
when it is also an Acc-VS
has an Applies to: field as follows:
Applies
to: Acc-VS
^ VVPAT
The
wedge ("^") character signifies that the requirement
applies to an accessible VVPAT
and that all requirements that apply to Acc-VS
and that apply to VVPAT
also apply to the accessible VVPAT.
Pictorially, this can be shown as follows in Figure 2; the dotted
lines indicate that the accessible VVPAT
is actually a device class that is instantiated when a requirement
applies to both Acc-VS
and VVPAT.
Figure
2: An instantiated accessible VVPAT device class
Classes
and how to use them are not immediately intuitive, yet they greatly
assist in making requirements specific to devices and allow new
devices to be instantiated or created (via the Innovation Class)
following orderly rules of device class inheritance. Table 1 shows
some common examples of how device classes are used in requirements.
Table
1: Examples for Applies to: fields
|
Applies
to:
|
Meaning
|
|
Vote-capture
device
|
Applies
to all Vote-capture devices
|
|
DRE,
Activation device
|
Applies
to all DREs and all Activation devices
|
|
DRE
^ Activation device
|
Applies
only to a DRE that is also an Activation device
|
|
Voting
device
|
Applies
to all voting devices (voting device is the superclass
of all voting device classes)
|
|
Voting
system
|
Applies
to the voting system as a whole; doesn't matter which
of the devices in the voting system satisfies the requirement
|
Voting
device is the highest level device class, i.e., superclass,
of all voting device classes, therefore a requirement that applies
to voting device applies to all voting devices. For example,
the requirement
Voting
devices designated for storage between elections SHALL continue
to meet all applicable requirements after storage between elections.
applies to Voting device because every device
comprising the voting system that is designated for storage between
elections must meet the requirement.
On
the other hand, a requirement that applies to Voting system
could apply to any of the voting devices comprising the voting
system; it doesn't matter as long as somehow the requirement is
satisfied. For example, the requirement
The
voting system SHALL prevent others from determining the contents
of a ballot.
applies
to Voting system because the voting system, as a whole,
must protect ballot secrecy. Not every device in the voting system
by itself may be able to protect ballot secrecy, but as a whole
the voting system must do this.
There
is a requirement listing provided immediately after the table
of contents in the VVSG. Readers can navigate through the document
using this list and quickly identify requirements in various sections.
Readers can also read the VVSG sequentially. There are 3 main
parts to the VVSG and two appendices:
-
Part 1: Equipment Requirements;
-
Part 2: Document Requirements;
-
Part 3: Testing Requirements;
-
Appendix A: Definitions of Words with Special Meanings in the
VVSG;
-
Appendix B: References.
As
noted previously, requirements throughout these parts that use
words with special meanings are linked to their definitions in
Appendix A. References in requirements and informative text are
linked to Appendix B.
Part
1: Equipment Requirements, contains requirements applying
to the voting system and the voting devices that it contains.
It is intended primarily for use by manufacturers and testing
labs. It may also be of use to election
officials in setting requirements for voting systems in
requests for proposals. It contains 8 chapters, organized as follows:
- Chapter
1: Introduction
-
Chapter 2: conformance-related information and requirements;
-
Chapter 3: usability, accessibility, and privacy requirements;
-
Chapter 4: auditing and records-related requirements;
-
Chapter 5: security-related requirements;
-
Chapters 6-7: core requirements and requirements arranged by
voting activity; and
-
Chapter 8: reference models - process model, vote-capture
device state model, and logic model.
Part
2: Documentation Requirements, contains requirements
applying to the Technical Data Package, the Voting Equipment User
Documentation, the Test Plan, the Test Report, the Public Information
Package, and the data for repositories. It is intended primarily
for use by manufacturers, test labs, and software repositories.
It contains 7 chapters, organized as follows:
-
Chapter 1: Introduction
-
Chapter 2: manufacturer requirements for quality assurance and
configuration management documentation provided to test labs;
-
Chapter 3: manufacturer requirements for documentation to be
included in the technical data package provided to test labs;
-
Chapter 4: manufacturer requirements for documentation provided
to users, i.e., customers;
-
Chapter 5: requirements for the voting system test plan, provided
by the test lab;
-
Chapter 6: requirements for the test report provided by the
test lab; and
-
Chapter 7: requirements for test results-related documentation
to be made available to the public.
Lastly,
Part 3: Testing Requirements contains requirements
applying to the conformity
assessment to be conducted by test labs. It is intended
primarily for use by test labs. Requirements in Part 1 and Part
2 reference sections in Part 3 to indicate the general methods
for how the requirements are to be tested (but not the tests themselves).
Part 3 contains 5 chapters, organized as follows:
-
Chapter 1: Introduction;
-
Chapter 2: an overview of the conformity
assessment process and related requirements;
-
Chapter 3: overview of general testing approaches;
-
Chapter 4: requirements for documentation and design reviews;
and
-
Chapter 5: requirements for different methods for testing.
|
