Take a sneak peek at the new NIST.gov and let us know what you think!
(Please note: some content may not be complete on the beta site.).
TECHNICAL GUIDELINES AND DEVELOPMENT COMMITTEE (TGDC)
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:
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:
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:
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.
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.
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
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
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:
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: