DOCSLIB.ORG

Voluntary Voting System Guidelines VVSG 2.0 Recommendations for Requirements for the Voluntary Voting System Guidelines 2.0

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Voluntary Voting System Guidelines VVSG 2.0 Recommendations for Requirements for the Voluntary Voting System Guidelines 2.0 Voluntary Voting System Guidelines VVSG 2.0 Recommendations for Requirements for the Voluntary Voting System Guidelines 2.0 February 29, 202010, 2021 Prepared for the Election Assistance Commission At the direction of the Technical Guidelines Development Committee 1 Acknowledgements Chair of the TGDC: Dr. Walter G. Copan Director of the National Institute of Standards and Technology (NIST) Gaithersburg, MD Representing the EAC Standards Board: Robert Giles Paul Lux Director Supervisor of Elections New Jersey Division of Elections Okaloosa County Trenton, NJ Crestview, FL Representing the EAC Board of Advisors: Neal Kelley Linda Lamone Registrar of Voters Administrator of Elections Orange County Maryland State Board of Orange County, CA ElectionElections Annapolis, MD Representing the Architectural and Transportation Barrier, and Compliance Board (Access Board): Marc Guthrie Sachin Pavithran Public Board Member Public Board Member Newark, OH Logan, UT Representing the American National Standards Institute (ANSI): Mary Saunders Vice President, Government Relations & Public Policy American National Standards Institute Washington, DC Representing the Institute of Electrical and Electronics Engineers: Dan Wallach Professor, Electrical & Engineering Computer Science Rice University Houston, TX Representing the National Association of State Election Directors (NASED): Lori Augino Judd Choate Washington State Director of Elections State Elections Director Washington Secretary of State Colorado Secretary of State Olympia, WA Denver, CO 2 Requirements for VVSG 2.0 February 29, 202010, 2021 Individuals with technical and scientific expertise relating to voting systems and equipment: McDermot Coutts Chief Architect/Director of Technical Geoff Hale Development Computer Security Expert Unisyn Voting Solutions Washington, DC Vista, CA Diane Golden Program Coordinator David Wagner Association of Assistive Technology Act Professor, Electrical & Engineering Programs Computer Science Accessibility Expert University of California-Berkeley Grain Valley, MO Berkeley, CA 3 Public Working Groups discussed and developed guidance to inform the development of requirements for the VVSG. • The Election Process Working Groups: Pre-Election, Election, and Post-Election Process Working Groups performed a great deal of up-front work to collect locale-specific election process information and, from that, to create coherent process models. • The Interoperability Working Group handled voting system interoperability including common data format (CDF) modeling and schema development. • The Human Factors Working Group handled human factors-related issues including accessibility and usability. • The Cybersecurity Working Group handled voting system cybersecurity-related issues include various aspect of security control and auditing capabilities. • The Testing Working Group handled voting system testing-related issues including what portions of the new VVSG need to be tested and how to test them. 4 Requirements for VVSG 2.0 February 29, 202010, 2021 Executive Summary The United States Congress passed the Help America Vote Act of 2002 (HAVA) [HAVA02] to modernize the administration of federal elections and to establish the U.S. Election Assistance Commission (EAC) to provide guidance to the states in their efforts to comply with the HAVA administrative requirements. Section 202 of HAVA directs the EAC to adopt voluntary voting system guidelines, and to provide for the testing, certification, decertification, and recertification of voting system hardware and software. The purpose of the guidelines is to provide a set of specifications and requirements against which voting systems can be tested to determine if they provide all the basic functionality, accessibility, and security capabilities required of voting systems. This document, the Voluntary Voting System Guidelines Version 2.0 Requirements (referred to herein as the Guidelines or VVSG 2.0), is the fifth iteration of national level voting system standards. The Federal Election Commission published the first two sets of federal standards in 1990 [VSS1990] and 2002. [VSS2000]. The EAC then adopted Version 1.0 of the VVSG (VVSG 1.0) [VVSG2005] on December 13, 2005. In an effort to update and improve Version 1.0 of the VVSG, on March 31, 2015, the EAC commissioners unanimously approved VVSG 1.1. [VVSG2015]. The VVSG 2.0 is a departure from past versions in that a set of principles and associated guidelines were first developed to describe how, at a high-level, voting systems should be designed, developed, and how they should operate. The VVSG 2.0 requirements were then derived from those principles and guidelines. The VVSG 2.0 requirements fitsfit within a framework of documents under the EAC Voting System Certification Program that include: • VVSG 2.0 Principles and Guidelines • VVSG 2.0 Requirements • VVSG 2.0 Testing and Certification Program Manual The Guidelines were designed to meet the challenges ahead, to replace decade’s old voting machines, to improve the voter experience, and provide necessary safeguards to protect the integrity of the vote.voting process. All sections of the prior VVSG versions have been reviewed, rethoughtre-evaluated, and updated to meet modern expectations about, which address how voters should interact with the voting system and how voting systems should be designed and developed. The VVSG 2.0 requirements represent the latest in both industry and technology best practices, requiring significant updates in many aspects of voting systems. The Guidelines allow for an improved and consistent voter experience, enabling all voters to vote privately and independently, ensuring votes are marked, verified and cast as intended, and that the final count represents the true will of the voters. Federal accessibility standards, Section 508, Information and Communication Technology (ICT) Final Standards and Guidelines [USAB18], and Web Content Accessibility Guidelines (WCAG) [W3C10] are referenced and highlighted. Voter interface requirements have been updated to incorporate recent usability 5 Requirements for VVSG 2.0 February 29, 202010, 2021 research and interactions that result from modern devices and now fully support accessibility throughout the voting process. The cybersecurity of voting systems has never been more important. Indeed, attacks from nation state actors on our elections infrastructure in 2016 led to a critical infrastructure designation. To limit the attack surface on voting systems, the Guidelines require that any election system, such as an e-pollbook or election reporting system, be air-gapped from the voting system. To ensure the integrity of the votevoting process, methods have been implemented to detect errors through the combined use of an evidence trail and regular audits, including risk-limiting audits (RLAs), compliance audits, and ballot-level audits, are now supported.. There is a dedicated section on ballot secrecy, preventing voter information from being carried through to the voting system, and two-factor authentication is now mandated for critical voting operations. Cryptographic protection of data and new system integrity requirements ensure that security protections developed by industry over the past decade are built into the voting system. These include risk assessment and supply chain risk management, secure configurations and system hardening, exploit mitigation, sandboxing and runtime integrity. The VVSG 2.0 requires the voting system to include the capability to useof using common data formats defined by the National Institute of Standards and Technology (NIST) and public working groups. The common data formats were created to make election data more transparent and interoperable. These formats can be used in addition to any native formats used by the manufacturer. Defensive coding practices, reliability and electrical requirements were reviewed, updated, and streamlined. Finally, guidance relevant to testing and certification has been moved to the EAC’s testing and certification manual. This document was produced by the EAC’s Technical Guidelines Development Committee (TGDC) working in conjunction with the National Institute of Standards and Technology (NIST)NIST to aid in developing guidelines for voting equipment and technologies for making accessible, accurate and secure elections possible. EAC staff must annually review the VVSG for proposed revisions. Determinations must be sent to the EAC’s Executive Director (or a person operating in that capacity) to begin the review process required by HAVA (review by the TGDC, Board of Advisors, Standards Board, and public comment review) to ensure timely adoption of revisions. Under the direction of the Executive Director, EAC staff in consultation with NIST staff may make minor technical changes to the requirements in a timely manner. This process may include, but is not limited to, the development of an appeals process for such minor technical changes. EAC staff is responsible for updating the test assertions and issuing requests for interpretation or notices of clarification, as needed, to ensure efficiency in the process. 6 Requirements for VVSG 2.0 February 29, 202010, 2021 Table of Contents Acknowledgements ............................................................................................................. 2 Executive Summary ............................................................................................................. 5 Introduction .......................................................................................................................
Load more

Recommended publications
  • Guide to Braille ASCII (Or “Computer Braille”)
    A Guide to Braille ASCII (or “Computer Braille”) Some electronic braille devices occasionally display information or require that users input information in “computer braille” or braille ASCII. Braille ASCII is not technically a braille code, but rather is a one-to-one mapping between braille characters and the QWERTY keyboard (a standard computer keyboard). If you have a braille font installed on your computer, that braille font is the same as “computer braille” when typing. This guide will provide you with an overview of what you need to know to be able to understand or enter text when a device says, “computer braille required.” Do Not Contract Since braille ASCII is a one-to-one mapping between the QWERTY keyboard and braille signs, there is no translation occurring, so contractions cannot be used. Instead of typing: ,l\is ,brl You would need to type: louis braille Because there is no translation occurring, you also cannot use braille indicators that don’t exist in print, such as the number indicator (dots 3-4-5- 6 #) or the capital indicator (dot 6 ,). Numbers Since the number indicator is a symbol that does not exist in print and cannot be used, all numbers are represented in the lower part of the braille cell with no number indicator preceding them. If you need to type a mixture of letters and numbers, such as a postal code like V6P 6G2, instead of typing: ,V#f,P #f,G#b www.prcvi.org March 2021 A Teacher’s Guide to Braille ASCII (or “Computer Braille”) You would type: V6P 6G2 Capitals Without being able to use dot 6 to indicate capitals, many devices will use 8- dot input to accomplish this.
    [Show full text]
  • Kemampuan Imajinasi Matematis Siswa Tunanetra Smplb Pada Pembelajaran Joyfull Learning Berbantuan Audio Geobraille
    KEMAMPUAN IMAJINASI MATEMATIS SISWA TUNANETRA SMPLB PADA PEMBELAJARAN JOYFULL LEARNING BERBANTUAN AUDIO GEOBRAILLE SKRIPSI diajukan untuk memenuhi salah satu syarat untuk memperoleh gelar Sarjana Pendidikan Matematika oleh Yusriza Firdausi Romdhiana 4101416042 JURUSAN MATEMATIKA FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM UNIVERSITAS NEGERI SEMARANG 2020 ii PENGESAHAN iii MOTTO DAN PERSEMBAHAN MOTTO 1. “Allah tidak akan membebani seseorang melainkan sesuai dengan kesanggupannya” (Q.S Al Baqarah: 286). 2. “Boleh jadi kamu membenci sesuatu, padahal ia amat baik bagimu. Dan boleh jadi (pula) kamu menyukai sesuatu, padahal ia amat buruk bagimu. Allah Maha Mengetahui, sedang kamu tidak mengetahui” (Q.S. Al Baqarah: 216) 3. “Sesungguhnya bersama kesulitan ada kemudahan. Maka apabila engkau telah selesai (dari sesuatu urusan), tetaplah bekerja keras (untuk urusan yang lain). Dan hanya kepada Tuhanmulah engkau berharap” (Q.S. Al Insyirah: 6 – 8). PERSEMBAHAN Kedua orang tua tercinta, Abah H. Muhammad Kusdi, M.Pd dan Ibu Hj. Unsa Laila, S.Pd yang senantiasa menjadi panutan, memberikan semangat dan penguatan, memberikan cinta dan kasih sayang, selalu tulus mendoakan, serta menemani setiap lagkah perjuangan. Semoga selalu diberikan umur yang panjang dan barokah. Amin. Kakak saya, Fahmi Rikza Luqmana dan Adrikna Niam serta adik saya M. Mirzasofa Sirrul Wafi yang selalu memberikan semangat dalam menempuh pendidikan dan terus mengalirkan doa. Keluarga besar yang selalu mendoakan dan mendukung dalam segala hal. iv PRAKATA Puji syukur penulis ucapkan kehadirat Allah SWT atas segala limpahan rahmat-Nya sehingga penulis dapat menyelesaikan skripsi yang berjudul “Kemampuan Imajinasi Matematis Siswa Tunanetra SMPLB pada Pembelajaran Joyfull Learning Berbantuan Audio Geobraille” ini dengan lancar di tengah-tengah wabah pandemic COVID-19.
    [Show full text]
  • International Standards, Approaches and Frameworks Relevant to Software Quality Management and Software Process Improvement
    International standards, approaches and frameworks relevant to Software Quality Management and Software Process Improvement To help organizations managing software quality and improving software processes several standards, models, approaches and frameworks have been developed during the last decades. The most widely known and recognized of them are presented in this document. • Capability Maturity Model (CMM) • CMM Integration (CMMI) • Personal Software Process (PSP) and Team Software Process (TSP) • ISO 9000 standards family • TickIT • ISO/IEC TR 15504 Information Technology - Software Process Assessment (SPICE) • ISO/IEC 12207 Information Technology - Software Life-Cycle Processes • BOOSTRAP • Rational Unified Process CMM Publication Date: Version 1.1 - February 1993 Description: The Capability Maturity Model for Software (SW-CMM or CMM) is a model used by organizations for appraising the maturity of their software processes and for identifying practices that will increase the maturity of those processes. It was developed by the Software Engineering Institute, in cooperation with industry representatives. The Software CMM has become a de facto standard for assessing and improving software processes. Through the SW-CMM, the SEI and community have put in place an effective means for modeling, defining, and measuring the maturity of the processes used by software professionals. The Capability Maturity Model for Software describes the principles and practices underlying software process maturity and is intended to help software organizations
    [Show full text]
  • A Stone Man Version
    Guide to the Software Engineering Body of Knowledge AA SSttoonnee MMaann Veerrssiioonn (Version 0.7) April 2000 A project of the Software Engineering Coordinating Committee (Joint IEEE Computer Society - ACM committee ) Corporate support by: Project managed by: Executive Editors: Alain Abran, Université du Québec à Montréal James W. Moore, The MITRE Corp. Editors: Pierre Bourque, Université du Québec à Montréal Robert Dupuis, Université du Québec à Montréal Chair of the Software Engineering Coordinating Committee Leonard L. Tripp, IEEE Computer Society Copyright © 2000, Institute of Electrical and Electronics Engineers, Inc. All rights reserved. PREFACE TO THE SWEBOK GUIDE 1. Software engineering is an emerging discipline but there are unmistakable trends indicating an 10. Purpose increasing level of maturity: 11. The purpose of this Guide is to provide a 2. w McMaster University (Canada), the consensually-validated characterization of the Rochester Institute of Technology (US), the bounds of the software engineering discipline University of Sheffield (UK), the and to provide a topical access to the Body of University of New South Wales (Australia) Knowledge supporting that discipline. The Body and other universities around the world now of Knowledge is subdivided into ten Knowledge offer undergraduate degrees in software Areas (KA) and the descriptions of the KAs are engineering. designed to discriminate among the various important concepts, permitting readers to find 3. w The Software Capability Maturity Model and ISO 9000 are used to certify their way quickly to subjects of interest. Upon organizational capability for software finding a subject, readers are referred to key engineering. papers or book chapters selected because they succinctly present the knowledge.
    [Show full text]
  • Viewplus Software Suite 7.0.7 User Manual Revision: 20200427
    ViewPlus Software Suite 7.0.7 User Manual Revision: 20200427 Contents I. Preface ............................................................................................................................... 3 II. Tiger Software Suite - Program Installation ........................................................................ 4 II.A. Installation ..............................................................................................................................4 II.B. Uninstallation ..........................................................................................................................8 III. VP License Manager ......................................................................................................... 9 III.A. Software Activation .............................................................................................................. 10 III.A.1. Activation on computer with internet connection .................................................................................. 10 III.A.2. Activation on computer without internet connection............................................................................. 12 III.B. Deactivation of Tiger Software Suite ..................................................................................... 15 III.B.1. Deactivation on computer with internet connection .............................................................................. 15 III.B.2. Deactivation on computer without internet connection ........................................................................
    [Show full text]
  • Guide to the Software Engineering Body of Knowledge
    Guide to the Software Engineering Body of Knowledge AA SSttoonnee MMaann VVeerrssiioonn (Version 0.5) October 1999 A project of the Software Engineering Coordinating Committee (Joint IEEE Computer Society - ACM committee ) Corporate support by: Project managed by: Co-Executive Editors: Alain Abran, Université du Québec à Montréal James W. Moore, The MITRE Corp. Editors: Pierre Bourque, Université du Québec à Montréal Robert Dupuis, Université du Québec à Montréal Project Champion: Leonard L. Tripp, IEEE Computer Society Table of Contents INTRODUCTORY TEXT FROM THE EDITORIAL TEAM KNOWLEDGE AREA DESCRIPTION : - Software Configuration Management - Software Construction - Software Design - Software Engineering Infrastructure - Software Engineering Management - Software Engineering Process - Software Evolution and Maintenance - Software Quality Analysis - Software Requirement Analysis - Software Testing APPENDIX A KNOWLEDGE AREA DESCRIPTION SPECIFICATIONS FOR THE STONE MAN VERSION OF THE GUIDE TO THE SOFTWARE ENGINEERING BODY OF KNOWLEDGE – VERSION 0.25 INTRODUCTORY TEXT FROM THE EDITORIAL TEAM The IEEE Computer Society and the Association for Computing Machinery are working on a joint project to develop a guide to the Software Engineering Body Of Knowledge (SWEBOK). This is the current draft (version 0.5 completed in September 1999) of the Stoneman version of the Guide1. Articulating a body of knowledge is an essential step toward developing a profession because it represents a broad consensus regarding the contents of the discipline. Without such a consensus, there is no way to validate a licensing examination, set a curriculum to prepare individuals for the examination, or formulate criteria for accrediting the curriculum. The project team is currently working on an update to this draft version of the Guide based on the results of the second review cycle.
    [Show full text]
  • Voluntary Voting System Guidelines VVSG 2.0 Recommendations for Requirements for the Voluntary Voting System Guidelines 2.0
    Voluntary Voting System Guidelines VVSG 2.0 Recommendations for Requirements for the Voluntary Voting System Guidelines 2.0 February 29, 2020 Prepared for the Election Assistance Commission At the direction of the Technical Guidelines Development Committee 1 Requirements for VVSG 2.0 February 29, 2020 Acknowledgements Chair of the TGDC: Dr. Walter G. Copan Director of the National Institute of Standards and Technology (NIST) Gaithersburg, MD Representing the EAC Standards Board: Robert Giles Paul Lux Director Supervisor of Elections New Jersey Division of Elections Okaloosa County Trenton, NJ Crestview, FL Representing the EAC Board of Advisors: Neal Kelley Linda Lamone Registrar of Voters Administrator of Elections Orange County Maryland State Board of Election Orange County, CA Annapolis, MD Representing the Architectural and Transportation Barrier, and Compliance Board (Access Board): Marc Guthrie Sachin Pavithran Public Board Member Public Board Member Newark, OH Logan, UT Representing the American National Standards Institute (ANSI): Mary Saunders Vice President, Government Relations & Public Policy American National Standards Institute Washington, DC 2 Requirements for VVSG 2.0 February 29, 2020 Representing the Institute of Electrical and Electronics Engineers: Dan Wallach Professor, Electrical & Engineering Computer Science Rice University Houston, TX Representing the National Association of State Election Directors (NASED): Lori Augino Judd Choate Washington State Director of Elections State Elections Director Washington Secretary
    [Show full text]
  • Lic. Ciências Da Computação Estrutura Do Tema ISC
    Introdução aos Sistemas de Computação Sistemas de Computação (1) Lic. Ciências da Computação Estrutura do tema ISC 1º ano 1. Representação de informação num computador 2007/08 2. Organização e estrutura interna dum computador A.J.Proença 3. Execução de programas num computador 4. O processador e a memória num computador 5. Da comunicação de dados às redes Tema Introdução aos Sistemas de Computação AJProença, Sistemas de Computação, UMinho, 2007/08 1 AJProença, Sistemas de Computação, UMinho, 2007/08 2 Noção de computador (1) Noção de computador (2) Um computador é um sistema que: Computador tipo – recebe informação, processa / arquiva informação, Sinais Processador Sinais transmite informação, e ... Digitais Periférico / (1 ou +) Periférico / Digitais –é programável Sinais Sinais Dispositivo Dispositivo i.e., a funcionalidade do sistema pode ser modificada, Digitais Digitais sem alterar fisicamente o sistema Entrada Memória Saída Sinais Sinais primária Quando a funcionalidade é fixada no fabrico do sistema onde o Analógicos Analógicos computador se integra, diz-se que o computador existente nesse sistema está “embebido”: ex. telemóvel, máq. fotográfica digital, automóvel, ... Arquivo Como se representa a informação num computador ? Informação Como se processa a informação num computador ? AJProença, Sistemas de Computação, UMinho, 2007/08 3 AJProença, Sistemas de Computação, UMinho, 2007/08 4 Representação da informação Noção de computador (3) num computador (1) Como se representa a informação? –com binary digits! (ver sistemas de numeração...) • Como se representa a informação num computador ? Tipos de informação a representar: – representação da informação num computador -> – textos (caracteres alfanuméricos) » Baudot, Braille, ASCII, Unicode, ... – números (para cálculo) » inteiros: S+M, Compl. p/ 1, Compl.
    [Show full text]
  • Guidelines and Standards for Tactile Graphics, 2010
    Guidelines and Standards for Tactile Graphics, 2010 Developed as a Joint Project of the Braille Authority of North America and the Canadian Braille Authority L'Autorité Canadienne du Braille Published by The Braille Authority of North America ©2011 by The Braille Authority of North America All rights reserved. This material may be downloaded and printed, but not altered or sold. The mission and purpose of the Braille Authority of North America are to assure literacy for tactile readers through the standardization of braille and/or tactile graphics. BANA promotes and facilitates the use, teaching, and production of braille. It publishes rules, interprets, and renders opinions pertaining to braille in all existing codes. It deals with codes now in existence or to be developed in the future, in collaboration with other countries using English braille. In exercising its function and authority, BANA considers the effects of its decisions on other existing braille codes and formats; the ease of production by various methods; and acceptability to readers. For more information and resources, visit www.brailleauthority.org. ii Canadian Braille Authority (CBA) Members CNIB (Canadian National Institute for the Blind) Canadian Council of the Blind Braille Authority of North America (BANA) Members American Council of the Blind, Inc. (ACB) American Foundation for the Blind (AFB) American Printing House for the Blind (APH) Associated Services for the Blind (ASB) Association for Education & Rehabilitation of the Blind & Visually Impaired (AER) Braille Institute of America (BIA) California Transcribers & Educators for the Blind and Visually Impaired (CTEBVI) CNIB (Canadian National Institute for the Blind) The Clovernook Center for the Blind (CCBVI) National Braille Association, Inc.
    [Show full text]
  • Appendix A: Quality Models and Verification Methods
    Appendix A: Quality Models and Verification Methods As indicated in previous chapters, we have excluded discussions on the various verification methods which still exist in many publications. The following table may be useful in researching appropriate methods to deal with the different artefacts in the product lifecycle. We do not claim completeness in the methods but have provided common verification methods which we apply in our projects. Artefact type Quality model Verification methods Documentation DocQMod • Peer Review • Structured Group Review • Inspection • Walk Through • Technical Review • Informal Review Business BPQMod • Peer Review processes • Structured Group Review • Formal Inspection (on business process models, e.g. swimlanes, business and application process models) • Walk Through • GUI Prototyping • Test Modelling (based on business processes) • Early Test Case Design • Usability Testing Requirements ReqQMod • Management Review • Peer Review • Structured Group Review • Audit • Inspection • Walk Through • Technical Review • Informal review • GUI Prototyping • Test Modelling (based on requirements) • Test Case Specification (based on requirements) (continued) M. Wieczorek et al., Systems and Software Quality, 165 DOI 10.1007/978-3-642-39971-8, © Springer-Verlag Berlin Heidelberg 2014 166 Appendix A: Quality Models and Verification Methods Artefact type Quality model Verification methods Architecture ArchQMod • Peer Review • Structured Group Review • Formal Inspection • ATAM • Prototyping (including functional and non-functional testing) • FMEA Database DataQMod • Formal Inspection (on e.g. normalisation) • Peer Review (on indexing, SQL statements, stored procedures) • Structured Group Review • Functional Testing (by application) • Non-functional testing (including performance and security) Source code CodeQMod • Peer Review • Walk Through • Formal Inspection (e.g. style guides, coding standards) • Static Source Code Analysis (tool based) • Profiling (e.g.
    [Show full text]
  • Transition Planning for Students Who Are Deafblind
    Transition Planning for Students who are Deafblind Coaching from Students, Parents and Professionals Citation: Ingraham, C.L. (Ed.) (2007). Transition Planning for Students who are DeafBlind. Knoxville, TN: PEPNet-South. These materials were developed in the course of agreement between the Research to Practice Division, Oce of Special Education Programs, U.S. Department of Education and PEPNet-South at the University of Tennessee, Knoxville under grant #H326D060003. Additional information about current pepnet 2 project activities and resources can be found at www.pepnet.org. Year of publication: 2007. Tablle of Contents Foreword.......................................................................................................................................................... 1 Introduction ..................................................................................................................................................... 3 The Purpose of This Monograph Chapter 1 – History of DeafBlindness................................................................................................ 7 A Brief History of Services for Deafblind People In the United States Chapter 2 – Who are the DeafBlind? .................................................................................................19 What Does It Mean to be DeafBlind – Really? Chapter 3 – Aids and Devices...............................................................................................................29 Aids and Accommodations for DeafBlind Students:
    [Show full text]
  • Appendix G Systems General Requirements
    BROADWAY SUBWAY PROJECT Commercial in Confidence PROJECT AGREEMENT EXECUTION COPY SCHEDULE 4 Appendix G Systems General Requirements BROADWAY SUBWAY PROJECT Commercial in Confidence PROJECT AGREEMENT EXECUTION COPY SCHEDULE 4: APPENDIX G: SYSTEM GENERAL REQUIREMENTS - 2 - Table of Contents 1 APPENDIX G – Systems GENERAL REQUIREMENTS .................................................................. 7 1.1 Introduction .......................................................................................................................................... 7 1.2 Requirements Delivery ........................................................................................................................ 7 1.3 Standards .............................................................................................................................................. 8 1.4 Systems Plan ........................................................................................................................................ 8 1.5 Design Life of the Systems .................................................................................................................. 9 1.6 Systems Design Management .............................................................................................................. 9 1.6.1 Requirements Specification Overview ............................................................................................ 10 1.6.2 Requirements Analysis Overview ..................................................................................................
    [Show full text]