Voter Data System System Requirements Specification · , Voter Data System, Statement of Project Scope”; produced by DC Design Studio; 11/7/2001 1.5. Overview This SRS follows the

Wayne Saucier, Web Development Consultant 545 W Fireweed Ln, Anchorage AK 99503-1927 • Voice (907) 258-5411 [email protected] • www.dcdesign.com • Fax (907) 258-5412

Voter Data System

System Requirements Specification

System Requirements Specification – Rev. 1.23.2002 Page 2

Change Control

The following information is being used to control and track modifications made to this document.

1) Revision Date: Author: Section(s): Page Number(s): Summary of Change(s):

2) Revision Date: Author: Section(s): Page Number(s): Summary of Change(s):


Table of Contents 1. Introduction .........................................................................................3

1.1. Purpose .......................................................................................3

1.2. Scope...........................................................................................3

1.3. Definitions, Acronyms, and Abbreviations....................................3

1.3.1. Campaign Terms ..................................................................3

1.3.2. Technical Terms ...................................................................3

1.4. References ..................................................................................3

1.5. Overview......................................................................................3

2. General Systems Description..............................................................3

2.1. Project Perspective ......................................................................3

2.1.1. System Interfaces .................................................................3

2.1.2. User Interfaces .....................................................................3

2.1.3. Hardware Interfaces .............................................................3

2.1.4. Software Interfaces...............................................................3

2.1.5. Communications Interfaces ..................................................3

2.1.6. Modes of Operation ..............................................................3

2.2. Product Functions ........................................................................3

2.3. User Characteristics.....................................................................3

2.4. General Constraints .....................................................................3

2.5. Assumptions and Dependencies .................................................3

2.5.1. Capacity................................................................................3

2.5.2. Timing...................................................................................3

2.5.3. Project Risks.........................................................................3


2.5.4. Campaign and District Considerations..................................3

2.5.5. Project Assumptions .............................................................3

3. Specific Requirements ........................................................................3

3.1. External Interfaces .......................................................................3

3.2. Functional Requirements .............................................................3

3.2.1. Mandatory for Phase I ..........................................................3

3.2.2. Important or Optional (implemented in Phase II or III) ..........3

3.3. Performance Requirements .........................................................3

3.4. Logical Database Requirements..................................................3

3.4.1. Conversion Requirements ....................................................3

3.5. Design Constraints.......................................................................3

3.6. Software System Attributes..........................................................3

3.6.1. Reliability Requirements .......................................................3

3.6.2. Availability Requirements .....................................................3

3.6.3. Security Requirements .........................................................3

3.6.4. Maintainability Attributes.......................................................3

4. Appendix A: Functional Requirements Grid ........................................3

5. Appendix B: Current Data Grid ...........................................................3

6. Appendix C: Voter File Data Dictionary, AB Data ...............................3

7. Appendix D: Existing Voter Data Screen.............................................3

8. Appendix E: Existing Walking List .......................................................3

9. Appendix F: Storyboard for "user mode".............................................3

10. Appendix G: Suggested User Manual Outline .................................3


1. Introduction

1.1. Purpose

The purpose of this System Requirements Specification (SRS) is to document the requirements for a voter data system. This document does not include a solution or a design for the solution. The solution may be provided by a custom application developer or by an independent software vendor with an existing solution (that may be customized).

This document will describe the requirements as either “mandatory,” “important,” or “optional." The next logical step in this project is to write a Request for Proposal (RFP) that references this SRS. The responses to this proposal will be evaluated for cost and compliance with the stated requirements of the project.

In summary, the purpose of this document is to

• Provide a method of conveying the complete requirements for the voter data system to a custom software developer or software vendor

• Increase the quality of the RFP responses

• Provide a baseline to evaluate the RFP responses

• Provide a basis for the design of the solution

This project can be considered to comprise two or three phases. Phase I is the “proof of concept” phase of the project. The intention is to replace the existing Access database with a web-based system and allow the campaigns to query and report on the data without the specific services of

staff personnel. Phases II and III, once the concept is proven, will be an enhanced version of the system to provide as much additional benefit as possible to the goals. If all of the desired functionality is provided in Phase II, there will not be a Phase III.

The second phase of this project will include a refined and enhanced version of this requirements document aimed to pick up campaigns where the original solution did not entirely meet their requirements.


1.2. Scope

wishes to increase their efficiency and reduce costs by developing new Information Technology tools aimed at better managing their voter and constituent databases and providing better tools for driving the campaigns.

The current technologies already used by for similar purpose include:

• A Microsoft Access database (with approximately 430,000 records) that is queried by party staff or volunteers.

• A small office network, consisting of four networked workstations on a Windows 2000 platform, and a high-speed DSL Internet connection

In the past, has attempted or achieved success in these areas by:

• Utilizing scarce human resources and basic knowledge of database management to provide for the informational needs of candidates across the state

Success of this project will be determined by:

• The relative ease with which the database’s intended audiences generate the desired reports and lists

• The real financial savings inherent in utilizing sophisticated ways of generating and maintaining mailing lists

• An improvement in the level of sophistication of campaigns run in districts across the state

1.3. Definitions, Acronyms, and Abbreviations

1.3.1. Campaign Terms

Down-ballot – Election races appearing "below" presidential, gubernatorial, and/or congressional races on voter ballots


GOTV – "Get Out The Vote," or efforts to encourage a certain targeted portion of the electorate to vote

Gubernatorial – Refers to the election for governor

Primaries – election method the state parties use to select a nominee to represent them on election ballots for each particular race

Household Merge – Merging distinct records of voters who live at the same house into a single record

1.3.2. Technical Terms ActiveX – A Microsoft software object development model.

Broadband – Transmission by modulated carrier - Data over TV cable is broadband, DSL is not.

Client – A system component running on the user’s computer providing a user interface. Clients communicate with a centralized computer called a server for data and functionality.

Collocation – Generally a contract-based agreement between an ISP and client allowing client equipment to be installed in the ISP’s network operation center.

Digital Subscriber Line (DSL) – a high-data-rate digital voice data service over copper telephone lines. DSL is an "always-on" service like a dedicated line.

Extensible Markup Language (XML) – A World Wide Web standard extending HTML by allowing user to create new tags enclosing new data types. It is being developed by the W3C Schema Working Group. Basically, HTML is for WWW documents, XML for data.

Graphical User Interface (GUI) – Typically a Microsoft Windows or Macintosh custom application sporting windows and other common controls.

Hyperlink – A click-able area on a web page that causes the web browser to navigate to another page, typically indicated by underlined text.

Hypertext Transport Protocol (HTTP) – The standard Internet protocol for communications between a web server and a web browser.


Internet Service Provider (ISP) – A service organization providing Internet access accounts. ISPs may also provide web hosting, collocation and other Internet related services.

Moderated – Refers to the process of reviewing changes and additions to data before committing those changes to the system.

Plug-in – a web browser software add-on providing functionality not originally available in the web browser.

Point-to-Point Protocol (PPP) – A protocol for establishing an IP network connection over serial lines and modems. It is replacing SLIP in many applications.

Remote Procedure Call (RPC) – The heart of Client- Server networking. Allows a client to initiate a procedure on a remote server, running it on the server instead of on the client as with normal networking

Server – Computer or Process offering services or resources.

Simple Object Access Protocol (SOAP) – Simple Object Access Protocol provides a way for applications to communicate with each other over the Internet, independent of platform.

Virtual Private Network (VPN) – A private network that is constructed by using public wires to connect nodes.

1.4. References

, Voter Data System, Statement of Project Scope”; produced by DC Design Studio; 11/7/2001

1.5. Overview

This SRS follows the ANSI/IEEE STD-830-1998 standard. This format helps ensure completeness and is the most accepted form of communicating the software requirements to a custom software developer.

As mentioned above, each requirement below is additionally classified as “mandatory," “important,” or “optional." The solution must include all of the mandatory requirements in this document. The most robust solution would include the most important requirements. The optional requirements will not be used strictly to evaluate one solution over


another, but gives a better understanding of the depth and completeness of the offering.

This document does not attempt to specify the design details of the desired system, only the requirements of the system. Design details, such as screen layouts and the formatting of the reports will be determined during the design of the project.


2. General Systems Description

2.1. Project Perspective

Every 2 years, starting in late spring, the embarks on a new campaign aimed at electing Democratic candidates into office. Information on registered voters is compiled through a number of means by the and then delivered to candidates at various times throughout the course of the campaign.

The database-related campaign process follows these basic chronological steps:

• In late spring of a campaign year, the party receives a voter database update from the state Division of Elections.

• All year round, that information is supplemented and updated through various means (polling, surveys, etc.).

• The database is utilized throughout the entire campaign to generate mailing lists, calling lists, and walking lists for candidates across the state. staff or volunteers generally conduct these queries and reports. The volunteers then deliver the information via email or hardcopy to the candidates. Additionally, candidates will need to have 2-4 fields in which to enter data that can be later queried.

The envisions a custom web-based solution implemented on a secure and highly available web-server. The does not foresee making a significant investment in hardware or other systems to implement this solution. They will likely lease a hardware system for the first year of the project.

The is also interested in devising an effective way to manage the perpetual updating process. As candidates visit voters door-to-door and conduct polling and surveys, the voter information in the database needs to be altered to reflect the voter nuances gleaned from these efforts.

The has not, however, reached a conclusive decision on how that can be most effectively done. The conundrum they face: On the one hand, the database will be most efficiently updated if those who interact with the voters can update it as the information comes to them. The problem with this scenario however, lies mainly along the lines of quality control. Unless the data is input following very specific guidelines, the database will slowly corrupt over time. Because the scope of this project


is intended to allow the most computer-illiterate of candidates to generate lists and reports, quality control will be a real issue.

On the other hand, if all of the updated information were routed through a central location, or staff person, at the that person would be flooded during the campaign season with a glut of information that they couldn’t possibly handle.

Ultimately, how the updating process should be handled is an internal decision the will have to make before looking for IT answers, but IT may also hold the key for making the updating process as efficient as possible.

2.1.1. System Interfaces The only existing or future related systems are as follows:

• Existing Microsoft Access database – This system is being replaced and will not require interface.

• personal computer systems – while certain have existing systems, there is no

need to interface with any, other than accessing the system via a standard web browser and Internet connection. The only exception is for printing labels and printing reports with specific pagination requirements. If labels and paginated reports are to be printed correctly on a printer attached to the local client computer, a custom printing component will need to interface with the local printing system for both data and driver details. There is no standard for party candidate and campaign worker computers and software. We assume most of the systems will be Intel based and running Microsoft Windows (various versions). It is possible there will be users on Macintosh or other operating systems.

• – The DNC does have existing systems and they do offer a service to update the data in XML format. The update process involves exporting the

data and sending to sends back the updated data that is imported back into the system. Under this scheme, technically a system interface does not exist.

2.1.2. User Interfaces The campaigns could be conducted from various locations on various unspecified equipment and operating systems. Large campaigns (such as gubernatorial campaigns) may have a dedicated and yet undetermined


location. Quite often candidates may wish to print reports, such as walking lists, from their home computer.

Because of the indeterminate locations and computers from which this system will be used, the system needs to have a web-based user interface. It would be impossible to determine client operating system requirements at this time, but we can assume all client computers will be web browser capable.

A web-based system for the user mode functions is mandatory. Microsoft Internet Explorer version 4.0 and greater compatibility is mandatory. Netscape 4.0 and greater compatibility is important.

Web-based functionality for the maintenance and administrative modes is important but not mandatory. Optionally the system could have dual interfaces. Web-based functionality and a Microsoft Windows 32 bit GUI with XML/RPC (such as the SOAP standard) type connectivity with the server (see section 2.1.5). The 32-bit GUI is optional but would enhance the environment for capable client systems.

A storyboard of the user interface has been developed in the process of defining these requirements, and is included with this SRS.

Following is a description of how the user interface may be developed to process a typical web based query:

1. A user calls up the web page, and clicks on a link to access the online voter database.

2. Arriving at an authentication screen, the user logs in with a unique username and password, which will allow them access to the records relevant to their election district ONLY.

3. The user arrives at a screen which asks them to select from a series of radio buttons or a drop down menu which kind of list they wish to generate: walking list, mailing list, phone list, mailing/phone list. The user clicks “next.”

4. The user selects which precincts to include in the list, and clicks “next.”

5. The user selects criteria from the following fields:

• Party affiliation

• Voting history


• Demographic data

• Issue-related fields

• Progressive/Conservative index

• Voter coding (input by candidate)

6. The user then selects from a number of options for sorting the results of their query, and clicks “next.”

7. The user then reaches a screen which informs them of the size (in records and file size) of the list they’re about to generate, and asks them how they would like the information delivered to them, selecting a print-out or downloadable file, or, in the case of a mailing list, a file that can be emailed to a mailing house.

When possible, the user interface should perform client-side data validation. While the database should maintain data integrity (server-side data validation), performing common checks for data validation at the client (32-bit GUI or web browser) will enhance the user experience and offer more efficient correction of data validation errors.

2.1.3. Hardware Interfaces This system will not have any defined hardware interfaces. The actual server operating system, hardware and location is yet to be determined. The does not have any preconceived notions of what hardware may be used. These decisions are left to the successful bidder of this project.

The only possible exception would be for printing labels. For the purposes of this project, we will assume all client computers are running a modern operating system such as Mac OS or Microsoft Windows, capable of abstracting the hardware layer. As a result, the label-printing portion of this system can assume to interface with the printing from an operating system software perspective and not a hardware perspective.

2.1.4. Software Interfaces Internet Explorer and Netscape Navigator have defined software interfaces. This system should use the common interfaces between both potential browsers when possible. If there is no common interface specification for a required function, the design should favor Internet Explorer version 4.0 and above.


In the event there is no browser-based software interface for a required function (possible limitation for label printing and report pagination), ActiveX or “Plug-ins” can be considered. No software should be required to be manually installed on the client computers for proper functionality of the system.

If an ActiveX control is chosen for printing functions, it will define the user interface for that function.

2.1.5. Communications Interfaces As mentioned previously, this system is assumed to have web-based client software for at least the normal user mode. The database and server functions will not necessarily be located on the same local network as the clients running in normal user mode. Establishing Virtual Private Network (VPN) connections from the various client workstations is not practical, thus communications is assumed to be Internet based.

The Internet communication protocol is by definition TCP/IP based and could be facilitated by any standard ISP type connection (Dial-up PPP, DSL, Cable Broadband, etc.). Navigation to the system would be via a World Wide Web hyperlink that could be saved in the client computer “favorites” folder.

In the case of web-based client software, client interface application to server application communications should be via the standard HTTP protocol without any extension that requires proprietary client-installed components (unless automatically installed via ActiveX or plug-in technology).

2.1.6. Modes of Operation The system will potentially have three modes of operation:

• Normal user mode

• Maintenance mode

• Administrative mode

The normal envisioned operation is that of the normal user (a candidate or other campaign user) making campaign-specific updates, running reports and queries. A simplified view of the security for this mode will minimally assume the user have the rights to query any campaign data and common party data, modify campaign data, but not modify common party data.


However the ability to modify 2 to 4 campaign specified data fields is mandatory for Phase I.

The maintenance mode would allow someone at the party headquarters to maintain the common party data. Typical functions would be creation and modification of existing voter data. Maintenance mode is mandatory for Phase I.

Administrative mode would allow someone at the party headquarters to create, manage and delete campaigns, and create, manage and delete user logon accounts. Other functions in this mode would include merging voter data updates (collected from the individual campaigns) to the common party data; the ability to apply externally acquired updates to the common data and export the campaign data or common data. Administrative mode is not mandatory for Phase I.

It should be noted, the successful system does not necessarily need to have three explicit modes of operation, but the above functionality does need to be accommodated.

2.2. Product Functions

This system must be designed to handle current and future campaigns. This system could be redeployed for each campaign (multiple systems running in parallel) or could be a single system designed to handle multiple campaigns. The prefers the latter but would consider any reasonable approach that meets the requirements stated in this document.

The system must provide at minimum the functionality of the existing Access Database. The primary difference between the envisioned “minimal” solution and the existing Access Database is that the existing system requires an analyst highly experienced with Microsoft Access to perform the data updates, reports, exports and queries.

Some of the highlighted features are (Phase I and II):

• Data management – the ability to add, delete and modify voter and campaign records in the database (maintenance mode and administrative mode).

• Data import and export – the ability to import and export all or part of the data to XML and comma delimited format.

• Mailing list generation with the ability to household merge and export the list to a downloadable comma delimited file (web based in user mode).


• Absentee list generation (Web based report in user mode)

• Walking list generation with the ability to household merge. (Web based reports in user mode)

• Phone list generation with the ability to household merge (web based reports in user mode)

Although the envisions this system to be used only for candidate campaigns, it would be desirable for the system to be generic enough to handle other types of campaigns such as ballot measures. It is important that the be able to control/monitor what kinds of data are accessible to any given person or group.

The successful solution needs to have robust functionality to help achieve a high level of “buy-in."

The successful solution must be able to filter and sort on almost any combination of voter data.

2.3. User Characteristics

The will typically employ at least one individual with basic computer and data management skills. This individual could be trained to use all three modes of operation but would typically be using the maintenance and administrative functions. The employee would also be the first point of escalation when individuals using the system require training, tutoring or other technical assistance.

Within each campaign, there may or may not be an individual with data management skills. However, we will assume that there will be at least one individual (the primary use of the system within the campaign) that is computer-literate. For the purpose of this document, we will assume that computer-literate means they could perform basic office automation and web skills without initial training, though training by the will be available.

As a goal, the normal user mode of the system should be as easy to use as the average consumer e-commerce web site. Since the system will most likely be web-based, we will assume that the successful system will make use of ergonomic features sported on many popular web sites today. Data updates, reports and data exporting should be easy and intuitive, not requiring explicit training to perform these common functions.

The successful solution needs to limit the ability to make mistakes.


Advanced and complex features should be optional for the user. This can be accommodated with an “Advanced Features” option in the user interface. This is an important feature, but may not be needed until phase II or III.

In general, the most successful design will reduce the skill and training requirements from a user perspective.

2.4. General Constraints

There are no regulatory, union, contractual or other constraints for this project.

2.5. Assumptions and Dependencies

2.5.1. Capacity The has the concept of a “Coordinated Campaign." This is essentially where the campaign purchases a package of campaign tools and services.

This system is targeted to the 60 legislative campaigns, governor/lieutenant governor campaigns and occasionally, a congressional campaign (20 state Senate campaigns, and 40 state House campaigns). This system would be available to all campaigns that buy in to the coordinated campaign, and could be made available on an individual basis to other campaigns that are compatible with the party.

The expectation is that a maximum of 30 campaigns will “buy in” and not all of those will likely use this voter data system in its first revision.

2.5.2. Timing This project has an aggressive set of requirements in a short time frame. Clearly this project must provide a minimal set of functionality in the first phase in order to meet the goals. The minimal functionality would be the implementation of a fault-tolerant server hosting the converted party data and providing the basic querying, reporting and updating functionality that the existing Access database now provides. As mentioned previously, this document classifies requirements as either “mandatory”, “important” and “optional”. Mandatory requirements also indicate what needs to be provided in phase one of this project.


Phase one of the system should be deployed by May 1st 2002 allowing the month of May for beta testing, retrofitting and training by June 1st 2002. All requirements identified as mandatory need to be accomplished in Phase I. The timing for Phase II of the project has not been defined. All important requirements must be accomplished in Phase II, while optional requirements may not be accomplished at all or be accomplished in Phase III..

After the first campaign season, the requirements would be further refined in preparation for the Phase II development of the system.

2.5.3. Project Risks There are a number of risks associated with this project:

• Lack of buy-in from legislators

o Overzealous expectations – the purpose and limitations of the system should be communicated up front.

o Complicated user interface – one of the top goals are to make sure that candidates that may be computer-illiterate will be able to use the system easily.

• Lack of training for campaign managers – they must have good user documentation and initial training.

• Unpredictable maintenance and customization budgeting – the project and solution must have predictable costs without constant unforeseen maintenance charges.

2.5.4. Campaign and District Considerations Districts change every 10 years.

Every district is different in terms of “change of address" needs. In the worst case, up to 1/3 of voters can move within a year (just the population, not necessarily voters). Some districts experience virtually no "change of address" needs.

With rural Alaska, walking lists are rarely used.

Voter ID data is considered “qualitative” and can change over time (voters' opinions can change).


2.5.5. Project Assumptions Although the initial budget for this project is small, the expects to lease their equipment and collocation services – this will not come out of the initial budget. Also, technical support and ongoing maintenance will not come out of the initial budget.

The assumes that the bid responses to this project will be for the “Phase I” requirements only. The “Phase II” requirements are only provided to ensure the design for Phase I is compatible with future requirements. Having said this, if additional Phase II or III requirements can be accomplished in Phase I, financially and or with respect to the timeline, the would like to have information to that effect.

The assumes the implementation of this system will begin with a review of the requirements and the creation of a project plan. Among other critical milestones, the plan should include a critical design review and a beta-test period.


3. Specific Requirements

3.1. External Interfaces

This system could be enhanced with the use of Personal Data Assistants (PDA) such as PalmPilots or iPaqs. However this would be totally optional for the foreseeable future.

3.2. Functional Requirements

NOTE: The functional requirements are summarized in an attached spreadsheet.

Although the envisions this system to be used only for candidate campaigns, it would be desirable for the system to be generic enough to handle other types of campaigns such as ballot measures.

3.2.1. Mandatory for Phase I User mode functions must be accessible from Internet Explorer 4.0 and above. It is also important to support Netscape Navigator 4.0 and above. Administrative or Maintenance mode functions must be accessible from a web-based browser or a 32-bit Windows GUI custom user interface. Data validation at the client side is mandatory to catch the obvious address parsing errors. See section 2.1.2 for more detailed user interface requirements.

It is mandatory that the system provide the ability to add, delete and modify voter records in maintenance mode. It is desirable to also be able to do this in user mode within a campaign. It the system provides this capability in user mode, it must allow review and moderation of those updates before applying the updates to common party data.

Although Phase I or this project assumes that the management and modification of the voter data will be performed by there must be up to four notes/memo fields associated with each voter record and maintained separately for each campaign. This field must be modifiable in user mode.

The system must be able to filter and sort on almost any combination of voter data voter data in the form of a custom report. Custom reports must also provide the ability to specify what fields (columns) will appear on the report.


The system must provide mailing list generation with the ability to export the list to a downloadable comma delimited file. The campaigns often make heavy use of direct mail. Most useful would be the ability to download an electronic file (merged by household) to send to a mailing house. Campaigns commonly send out 5 - 15 direct mail pieces per election, each to a different subset of their electorate.

Walking list generation and literature drop (lit. drop) lists are the same reports for development purposes. Both reports are mandatory web based reports. Optionally the walking list report could provide the ability to limit the list to a specified number of homes

All walking list reports must paginate properly. In other worlds a single record should not break across pages. We can assume any one record on a walking list will fit on one 8.5 x 11 page. Typically reports would also have a cover page summarizing the query and standard headers and footers.

The system must be able to generate a daily report of absentees in user mode as well as the ability to manually enter absentee information in maintenance mode. The absentee information would include a flag indicating the voter’s status as an absentee, their absentee address and ascension number.

The system must provide phone list generation (web-based report). Phone lists would commonly be used for the “GET OUT THE VOTE” (GOTV) initiative. There would be a call for the Democratic Party to each democrat voter prior to election night (regardless of the individual campaigns). As part of this process a poll-watching list (sorted alpha by precinct) would be generated for someone to watch the polls and mark people off during the election. This allows voters that have not voted yet during Election Day to be called to vote before the end of the day.

It is mandatory that household merges for mailing lists can be specified as an option for a mailing list report.

Also mandatory are phone number merges for phone list reports.

Each predefined report described above must provide a standard set of filter and soft options to be selected in user mode.

Mandatory is the ability to make maintenance changes of addresses and other data updates that are not campaign specific.

It is mandatory that the developer provide system design documentation (as-built). Both an on-line and written user manual outlining procedures for basic functions in each of the three modes must be provided.


Example walking list report

Filter: Filtered on the specified precinct

Sort Order: Sorted on the following:

1. Precinct

2. Street Names (alphabetically)

3. Street Address (sorted by odd/even)

Fields:

• Precinct

• Street Address

• Occupants

• Voter ID information

• Campaign Information – 2-4 fields

• Purchased Information

• A memo area

3.2.2. Important or Optional (implemented in Phase II or III) The system must provide the ability in administrative mode to add, delete and modify campaign definitions as well as add, delete and manage user accounts for each campaign.

The system must provide the ability to import and export all or part of the data to XML and comma delimited format.

Customized queries & reports need to be save-able. Saved queries and reports should be able to be copied, modified and re-saved.

Advanced and complex features should be optional for the user. This can be accommodated with an “Advanced Features” option in the user interface.

Mailing list generation with the ability to print labels to a printer attached to the local client computer running Microsoft Windows with Internet Explorer 4.0 or above would also be important. Mailing list generation with the


ability to print labels to a printer attached to the local client computer running Netscape Navigator 4.0 or above or not running Microsoft Windows is optional.

Optionally the system would automatically generate intelligent walking routes (much like a mail route) for most efficient walking from home to home. The optimal walking order could also be overridden based on feedback from campaign workers that become familiar with the route. This could be done over time based on feedback from the campaigns or someone could take the time prior to an election to drive the routes and provide feedback.

Household merges for queries other than mailing lists are important but not mandatory.

An important feature is the ability to generate a report of logon and logoff activity for user mode accounts. Optional is the ability to generate a report of detailed usage activity (reports, queries, etc.) for user mode accounts.

This system does not need to accommodate “campaign contributions." Most candidates will be leery about sharing “donor” information.

The system must support moderated updates to the data where an staff member reviews recommend updates to base data before being applied to master database (a Quality Assurance measure).

The system must be able to export all data from a campaign for the candidate to archive, analyze and etc.

Address parsing and formatting for bulk rate purposes (and automatic update of permanent records) are an important features.

3.3. Performance Requirements

Many of the reports and queries could be executed concurrently, especially during the end of the campaign, and the performance must be adequate. The successful solution must provide reasonable assurance that during the peak usage of the system (typically the week up to and including election days—both primary and general), the system will perform predictably and adequately. Under peak load the queries and reports should only take a few minutes maximum to accomplish. There should not be a significant increase in the time required to accomplish a query or report during peak usage as opposed to non-peak usage.

In the worst-case scenario, the system could be performing queries and data exports for up to 60 concurrent campaigns.


The worst-case period is the week before and including election night. During this time frame we can assume that most of the queries and reports will be done during the period of 11 AM and 7 PM. During this time, assume that there will be on average 6 reports with 20,000 records each per campaign.

3.4. Logical Database Requirements

There are four types of voter data this system needs to maintain.

• “Voter ID” data – data collected by the that profiles voters on political orientation and stance on specific issues. This data should be updateable from the efforts of the using this system. Voter ID data is considered “qualitative” and can change over time (voters' opinions can change).

• State Division of Elections data – data provided by the state and updated periodically. These updates would be in the form of a data import.

• Purchased data – this would be available from the state (i.e. hunting licenses) or other sources such as Motznik computer services. This data would be entered periodically in the form of a merge.

• Campaign data – data specific to a campaign, such as whether someone has visited the household or the voter’s voting intention. Typically the voter’s intention would be either coded as 1-5 (5 being a definite vote) or could be classified as definitely, probably, etc. This data would be collected and entered during the campaign. For Phase I of this project, it is likely that the voter code data be the only updateable field in user mode. If this feature adds significant cost to Phase I of the project, it may be delayed until Phase II.

It would be desirable to share and maintain as “party data” some of the fields from the types of data defined above. For example, the order of records printing on a walking list report is dependent upon the location of dwellings, not the name of the voter. The optimal solution would store address and walking list fields in a table universal to all campaigns, where other data would be best maintained per campaign.

Voter ID data, campaign data, and updates to personal voter information (such as addresses and phone numbers) should be updateable by the individual campaign workers. However, mistakes made to common data should not affect the integrity of the data for other campaigns. One


envisioned method of achieving this goal is to create “update records” unique to each concurrent campaign. The update records would override the common party data, but only for the campaign that created the update record. Once the elections are over, an worker could “merge” the update records into the common party data. This would also allow for quality assurance of the updates by an staff member.

Attached to this SRS (appendix B) is a grid specifying the data requirements for the system. The grid includes a description of each field, where the data is obtained from, and who will be able to either read from, or write to, the field.

This grid is based on the fields in the existing Access Database. The database developed must allow for the ability to add fields and make minor changes to the data schema to accommodate future campaigns with unpredictable requirements. This would typically be the addition of a field such as fishing license information.

In general, the individual campaigns can share any of the State Division of Elections data and any of the purchased data. Although it may be beneficial to share Voter ID data and Campaign data among other campaigns, this would generally not be done until after the primaries. Other data sharing requirements are described in appendix B.

The system should also have a number of custom fields that could be used in any way desired by the individual campaigns. Two to four custom fields for memos, free form notes or where “coding” of voters can be recorded, in Phase I would be adequate. Up to 15 custom fields would be adequate for Phase II.

The system must have transaction integrity. Session failure in the middle of a transaction should not cause data integrity problems.

3.4.1. Conversion Requirements A data dictionary (“Voter File Data Dictionary, AB Data”) for the existing

Access Database is included in Appendix C. This database includes approximately 430,000 records. It is currently stored in Microsoft Access version 9.0. The plans to “prune” this database prior to the data conversion. Initially this data needs to be converted into the new data system.

In addition there are many ongoing data import/merge requirements that will happen in the normal course of a campaign season. Initially these can be done manually.


Purchased data provided in a variety of formats would need to be merged into the system (it is collected externally). An example is an updated phone number list from Motznik. A system needs to be defined for making mass imports to the database.

Additionally a voter list from Division of Elections is typically imported in June of an election season and than again after the primaries in August.

The system must have the ability to export the voter data to an XML format (specified by and then re-imported into the database.

3.5. Design Constraints

The has no preconceived notion of the manufacturer's software, development tools or architectures to be used in developing this system, with the following exceptions.

In the case of 32-bit GUI, a standard Remote Procedure Call (RPC) protocol and data delivery protocol such as XML should be used. A likely choice would be the emerging Simple Object Access Protocol (SOAP).

Distributed Component Object Model (DCOM) should not be considered for client to server communications via the Internet. DCOM would be acceptable for client to server communications on the local network only.

3.6. Software System Attributes

3.6.1. Reliability Requirements Loss of data must be avoided. The common party data should be backed up to tape or optical media after each election season for archival and recovery purposes.

During the campaign season the data must be backed up on a daily basis and potentially restored to a redeployment of the system in the event of disaster. Full system recovery should not take more than 4 hours to accomplish. The system must have enough redundant components and readily available spare components to accommodate this requirement.

Other system integrity considerations such a virus protection or the potential for malicious destruction of data or denial of service type attacks must be addressed.


3.6.2. Availability Requirements This system must have redundancy, fault tolerance and a disaster recovery plan.

While reliability requirements are discussed in section 3.6.1 above, this section deals with temporary loss of access to data and is closely related to the performance requirements (section 3.3).

Loss of access to the system for the purpose of updating campaign data and generating reports (walking lists, etc.) from the period of Saturday through Tuesday of election night would be disastrous.

The system must have redundancy in the form of mirrored drives, power and other controllable components. Additionally, uncontrollable components, such as the main data communications infrastructure from a collocation facility must be considered as well.

Although downtime at anytime during a campaign would cause loss of confidence and “buy in” for the system, the risk of significant downtime during the critical portion of the campaign mentioned above must be virtually eliminated.

In the event of loss of communications to the server and database via all conventional methods of communication, for more than a few hours, there must be a backup plan. This plan may involve redeployment of the system at a backup location, alternative methods of data communication or other solutions offered by the vendor.

The fault tolerance of the entire system must be considered from server to client workstation.

The solution must provide for technical support. During the off-season, technical support can be provided during the provider’s normal business hours. However, during the campaign season, technical support must be provided during normal business hours as well as extended hours for emergency support. The campaign season is from June 1 to November 5th (election Tuesday). A support option must be provided from 8:00 AM to 11:00 PM during the campaign season.

3.6.3. Security Requirements Each campaign’s data must be separate and secure between campaigns. Although “down-ballot” campaigns may be given access to see other campaign data, they would never be given the ability to change another campaign’s data. The actual function of granting rights from one


campaign to another must be controlled by staff and not campaign staff.

As mentioned above the ability for one campaign to see another campaign’s data would typically be allowed after the primaries.

Individual campaigns should not be allowed to directly change any common or party data. An staff member must moderate any changes to common or party data. Campaigns could make changes to voter data and their data set would be active for them, but someone at the party HQ would conduct changes to the master data after approval. The verification by moderator is a potentially time-consuming and complicated process.

The staff member trained and designated at the “System Administrator” would be the individual to set up the initial security for the system. This individual would implement all security configurations. The rights granted among campaigns would be at the field level.

The system must be sabotage-proof. There is potential for Denial of Service (DOS) type attacks and malicious destruction or modification of data. These attacks could originate externally or even from trusted internal members of the system.

3.6.4. Maintainability Attributes The system should not be designed as to require the services of a specific ISP or hosting provider. Any specialized equipment proposed should be standard with typical ISPs and hosting providers. Any equipment purchased by the should be suitable for collocation.

The must have the ability to backup and archive their data. Not only will the data be exported for the individual campaigns (once the campaign is over), the entire data set may need to be restored for fault tolerant or archival purposes. This should be a function that can be performed by trained personal rather than an outside specialist.

System design that requires specialized training or highly specialized skills to perform routine maintenance should be avoided. If specialized training or skills for maintenance can’t be avoided, a maintenance schedule and pricing should be included with the proposed solution.


4. Appendix A: Functional Requirements Grid


5. Appendix B: Current Data Grid Legend

O: Origin of data

Phase: Phase of implementation

WCR: Who can read

WCW: Who can write


6. Appendix C: Voter File Data Dictionary, AB Data


7. Appendix D: Existing Voter Data Screen


8. Appendix E: Existing Walking List


9. Appendix F: Storyboard for "user mode"


10. Appendix G: Suggested User Manual Outline

Documents

Voter Data System System Requirements Specification · , Voter Data System, Statement of Project Scope”; produced by DC Design Studio; 11/7/2001 1.5. Overview This SRS follows the