Using The VVSG

Using The VVSG

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.

 

Requirements Language and Structure

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-ATest Reference: Part 3 Section 3.2 DISCUSSIONThese 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-ATest 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.

 

The Conformance Clause and Classes

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:

1. 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.
2. 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.

Inheritance in device classes

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.

 

Instantiated device classes

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

 

General device class usage in requirements

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.

 

Navigating Through Requirements

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.