VVSG and Requirements
Management
Ed Smith
January 13, 2011
Questions/Comments:
Ed Smith [email protected]
Opening Thoughts
• VVSG some of the most important
requirements for voting systems and their
surrounding development system
• Poorly executed RM is a cause of project
and product failure
• Requirements elicitation is important
• Organizing
– Development Systems
– Product: software, hardware, voter/pollworker
interfaces
Requirements Definition
Before it all starts…
• The Introductions
–
–
–
–
–
Both Volume I and Volume II
History, Intent, Summaries of each Volume
Much the same for both Introductions
Overview in Volume I
Glossaries
• TDP (Technical Data Package) production
Volume II, Section 2 Description of the Technical Data Package
Before it all starts…
• VVSG requirements for Quality Assurance
• VVSG requirements for Configuration
Management
The testing also evaluates the completeness of the vendor’s
developmental test program, including the sufficiency of vendor tests
conducted to demonstrate compliance with stated system design and
performance specifications, and the vendor’s documented quality
assurance and configuration management practices. The tests address
individual system components or elements, as well as the integrated
system as a whole.
• Select a development method
•Educate Developers with respect to VVSG
Then Development Starts
• Each section results in inputs to documentation
–
–
–
–
Requirements Specification
Functional Specification
Engineers’ Documents/Technical Solution
Test Specification/Test Plan
• Test Cases
– Manufacturing Specification
– Project Plans
VVSG
CERT
PROG
MANUAL
LAB
PROG
MANUAL
EXT
REFERENCES
STATE
STATUTE
CUST
PREFERENCE
CM PLAN
QA PLAN
REQUIREMENTS
SPECIFICATION
FUNC
SPEC
PROTOTYPE
TEST
DOCS
Bi-directional
traceability
Then Development Starts
• Each section results in inputs to documentation
– Volumes I and II result in Quality Assurance
Planning
• Audits
• Product Testing
–
–
–
–
Reliability
Accuracy
Durability
Real World Validation vs. Verification
Then Development Starts
• Each section results in inputs
Overview Voluntary Voting System Guidelines
Section 1 Introduction
Section 2 Functional Requirements
Section 3 Usability and Accessibility Requirements
Section 4 Hardware Requirements
Section 5 Software Requirements
Section 6 Telecommunications Requirements
Section 7 Security Requirements
Requirement: voting machine allows access to
a range to needs
CM PLAN
Sub-requirement: …including low vision and
QA PLAN
lack of motor control of hands
Sub-requirement: machine shall have a tactile
box with buttons for… and a 3.5mm input
REQUIREMENTS
Sub-requirement: Braille shall be
SPECIFICATION
embossed on each tactile button
Function Spec:
Tactile box shall allow for left/right,
Volume and speed…
Tactile box 3.5mm input shall accept
5 volts, stereo…
Braille dots shall be 1mm hemispherical
FUNC
SPEC
PROTOTYPE
TEST
DOCS
Bi-directional
traceability
Function Spec:
Tactile box shall allow for left/right,
Volume and speed…
Tactile box 3.5mm input shall accept
5 volts, stereo…
Braille dots shall be 1mm hemispherical
Test Spec:
With an election containing…
Ensure function of all tactile buttons
Ensure function of 3.5mm input
Ensure readability of Braille
Test Script:
Code an election…
Attach tactile box…
Scroll through the ballot using…
Attach a power supply and input 5V…
CM PLAN
QA PLAN
REQUIREMENTS
SPECIFICATION
FUNC
SPEC
PROTOTYPE
TEST
DOCS
Bi-directional
traceability
Requirements---Guiding
Principles
• Must specify what is needed, not the
solution (example of machined aluminum
housing)
• Complete to an engineering level of detail
• Requirements are developed by engineers,
not by marketing department or users
• Capturing the requirements may consume
as much as 30 percent of the entire project
time budget
Requirements---Guiding
Principles
• Unambiguous (objectively verifiable)
• Quantitative limits expressed with a realistic
measurement tolerance
• Self-consistent
• Environment completely characterized
• Completeness and relevance of external
references
Lack of RM Allows
• Scope Creep
• Developing the wrong product
Requirements imprecision
• Problems arise when requirements are not
precisely stated
• Ambiguous requirements may be interpreted in
different ways by developers and users
• Consider the term ‘appropriate viewers’
– User intention - special purpose viewer for each
different document type
– Developer interpretation - Provide a text viewer that
shows the contents of the document