systems engineering capstone project

7/28/2019 Systems Engineering Capstone Project

http://slidepdf.com/reader/full/systems-engineering-capstone-project 1/32

TABLE OF CONTENTS Page No.

I. Introduction……………………………………………………………………………………………………..

A. Background………………………………………………………………………………………………..

B. Problem Statement and Objective……………………………………………………………..

C. CONOPS…………………………………………………………………………………………………….. II. Technical Approach………………………………………………………………………………………….

A. SOW…………………………………………………………………………………………………………..

B. Analysis Plan………………………………………………………………………………………………

III. Problem Analysis……………………………………………………………………………………………..

A. CATWOE Analysis………………………………………………………………………………………

B. Objectives………………………………………………………………………………………………….

C. Constraints………………………………………………………………………………………………..

IV. Requirements Analysis…………………………………………………………………………………….

A. Requirements Development………………………………………………………………………

B. Requirements Derivation………………………………………………………………………….. V. Analysis of Alternatives……………………………………………………………………………………

A. Identify Alternatives…………………………………………………………………………………..

B. Risk Analysis and Mitigation………………………………………………………………………

C. Technological and Economic Feasibility and Analysis…………………………………

D. Scoring Alternatives …………………………………………………..

E. Sensitivity Analysis of Criteria Weighting………………………………………………….

VI. Architecture Solution………………………………………………………………………………………

A. Detailed description of solution………………………………………………………………..

B. Testing, Validation, and Verification………………………………………………………….

C. Implementation Plan………………………………………………………………………………… VII. Conclusion……………………………………………………………………………………………………….

VIII. References……………………………………………………………………………………………………….

IX. Appendix………………………………………………………………………………………………………….



1

I. Introduction

A. BACKGROUND

In an ever evolving technical landscape, nations and institutions must be vigilant in keeping up

with the advancement of modern times. Technologies, and its utilities, have changed the manner in

which most Americans educate themselves, execute their financial responsibilities, and essentially

retrieve all relevant levels of information in order to efficiently manage their academic, professional,

and personal lives.

While a massive portion of the private sector has transitioned into the Information Age of

modernization through electronic communication, technical commercial trade, and academic

enhancements brought on by standardized usage of modern technology, many of the federal

government institutions lag behind in this respect. Specifically, their out of date systems do not allow

for the implementation and deployment of an efficient means of engagement and interaction that

mainstream technology provides to most Americans.

The voting system in the United States, at both the federal and local levels, is amongst the mosthighly visible and scrutinized examples of how a governmental function has failed its registered voting

citizens. The voting system has received great public scrutiny for the administering of the registration

and voting processes as evidenced by high profile elections such as the Presidential race in 2000, and

the highly controversial Ohio Gubernatorial race in 2004. This system has also generated great criticism

for the means it both provides and fails to provide in the form of tally counts.1

Presently, adult citizens of the United States who are residents of one of the fifty states or the

District of Columbia may not be restrained from voting for a variety of reasons stated in the 15th

, 19th

,

24th

, and 26th

Amendments of the United States Constitution. Research and studies over the past

decade have shown that while this basic civil right is clearly defined, its execution is flawed.2

In the 2000 Presidential Election, the state of Florida’s election votes had to be recounted as theadministration and tally count of votes was riddled with conflicting results released by poll counters.

Due to time constraints, national pressure, and protests, the official recount failed to account for a true

consensus vote at a state level accurately and efficiently. It was widely reported and documented that

several counties within the state had their votes dismissed due to failed repeat voter turnout on time,

and that the manual chad vote counting system had confused voters with regard to whom they were

actually voting for. This was the first time in American history that the democratic process and its voting

systems were under such high levels of stress and scrutiny.1

The 2004 Gubernatorial race of Ohio brought about even more scrutiny at a national level

regarding local administration of elections at state levels, and raised valid concern amongst citizens in

states with similar local assembly infrastructures in place. Leading up to the election in Ohio, local

Republican Secretary of State and Republican Governor Nominee Ken Blackwell enforced manydecisions regarding the election process that ended up placing restrictions on voting for registered

citizens. Political analysts responded by saying that Blackwell's newly proposed voting decisions would

ultimately suppress the turnout among diverse low middle class populations within the state which were

leaning towards, and expected to vote for Democratic nominee Ted Strickland.7

Political experts believed that these pre-election decisions by Blackwell represented a

tremendous conflict of interest as he was a co-chair of President George Bush's re-election campaign in



2

2004. Due to the overwhelming belief that Mr. Blackwell was aiming to sway the state’s political seats in

favor of the Bush Administration, local reaction turned to amending the local Ohio Constitution to

remove oversight of elections from the Secretary of State’s responsibilities and to generate true election

reform at the state level. At the conclusion of this election, in which Democrat Ted Strickland actually

ended up ultimately winning, it was revealed that exit polls displayed a greater lack of confidence by

voters in Ohio in comparison to what ended up being a five week recount in Florida during the

previously mentioned Presidential Election recount of 2000.7

As recently as the 2008 Presidential election, it has been reported by independent election

reform researchers that 2.2 million voters across the nation did not have their votes accurately

accounted for due to failures of the authentication of voter registration at the state and county levels

across many regions in the country. As a result, the Federal Election Committee (FEC) was tasked by

Congress to modernize and standardize the voting system for all states and US territories.8

Our group has been assigned as the engineers to propose, design, develop, and ultimately

deploy a new modernized and standardized voting system across the national and local electoral

landscapes to improve the process, and to increase confidence in voters at the registration and actual

voting points in the political process. It is our mission to utilize the most cost effective technologicalmeans to make it easier for voters to participate in the process, to reduce the costs of voting per

individual over the long term, to use resources and energy more efficiently in the process, and to

revolutionize the democratic process so that exercising this essential right of each registered citizen is a

firm and solid representation in one’s political views by the 2016 Presidential Election.

B. PROBLEM STATEMENT AND OBJECTIVE

As a team we composed the following problem statement: The current national voting system

has caused a decrease in voter satisfaction by 24.2% over the last five years, creating an anticipated 20%

decrease in voter turnout over the next four years.

Our team objective is to be able to increase voter satisfaction by over 25%.

C. CONOPS

Our project team created a Concept of Operations (CONOPS) document to capture the FEC’s

view of the voting system. The CONOPS describes the intentions of the voting system and provides

details about what the FEC deems necessary for the new system to be successful. The document has a

basic description of the i VOTE system; the FEC goals of the i VOTE system; a list of objectives that the

i VOTE system should accomplish; strategies for handling certain parts of the systems engineering

process (implementation, testing, etc.); tactics for ideas on functional components, processes, and

voting system changes; possible policy changes; constraints for the voting system; and assumptions that

are made. The CONOPS, along with the Systems Analysis Worksheet (SAW) and brainstorming, aidedthe process of deriving the objectives and their associated metrics and targets.



3

II. Technical Approach

A. SOW

The Statement of Work (SOW) documents the list of work steps and deliverables we are

providing on the project to the FEC. It provides a binding agreement with the FEC and provides a

boundary for the scope of the project deliverables. We broke the project down into three main phases:

proposing the i VOTE project; defining the voting system; and architecting the final solution. For the

project proposal phase, we stated that we would create a CONOPS document for the i VOTE system;

perform CATWOE analysis; capture content for the first part of the Systems Analysis Worksheet; define

the problem statement and objective; provide a system boundary definition; create a Work Breakdown

Structure (WBS); define the team’s work assignments; and draft a schedule for performing the work

assignments on the i VOTE project.

In the system definition phase, we stated we would decompose the objectives down to lowerlevel objectives and define metrics and targets for each (and provide an objectives tree); create a

functional decomposition diagram; create use case diagrams for the high level functions; state the

requirements; provide several architecture alternatives; analyze the architecture alternatives; perform

risk assessment on the alternatives; complete an economic analysis; provide a final architecture solution

by scoring the alternatives and performing sensitivity analysis on the weights for the evaluation criteria.

During the system architecture phase, we articulated that we would provide a detailed

description of the chosen solution; create the architecture depictions (OV-1, 2, 3, 5; SV-1, 5; AV-1);

describe the testing, verification, and validation of the chosen solution; create an initial implementation

plan; and provide this final report. The sections in this final report demonstrate that we have completedthese tasks.

B. ANALYSIS PLAN

Group 2 utilized systems engineering techniques learned during this cohort and applied them

towards increasing voter satisfaction and modernizing the voting system. We used the formal

methodologies from the systems engineering classes to demonstrate that we have a thorough

understanding of the systems engineering process and lifecycle. At each phase of the process, we

applied the necessary techniques (such as systems analysis worksheet (SAW), brainstorming,

stakeholder elicitation (CONOPS), functional decomposition, use cases, alternatives scoring, etc.) to aid

in formulating the foundation and the design of the new modernized and standardized voting system.We also used tools, like the MITRE Risk Tool for risk analysis and Robust Decisions Accord for

stakeholder weighting of architecture criteria, to help achieve what was needed to be accomplished at

each of the phases.9,13

To design the new voting system, we first created a blueprint by creating a sound set of

requirements based on the objectives and associated metrics and targets (derived from the CONOPS



4

and SAW). Then we explored functional elements to perform the functions outlined in our functional

decomposition and satisfy our requirements. After ruling out numerous element options, we were able

to create three main architectures that could fulfill the functions and requirements.

We then analyzed the risks involved with each architecture, ranked the risks based on level and

likelihood, and created mitigations for each. Next, we considered costs associated with thearchitectures. We also explored ways to save money across all three architectures (such as using

virtualization for servers). After that, we created a scoring scale for the criteria (based on all of the

objectives), then scored and weighted the criteria based on expert judgment to establish an overall

score for each architecture. Using sensitivity analysis, we assessed the appropriate weighting of the

criteria. We then used all of the architecture analysis to deduce the optimal solution.

Once we found the optimal solution, we showed how the new voting system will be verified and

validated (using queue simulation, etc.) and how the new system should be tested to make sure it is

performing at the levels stated in the objectives. Lastly, we created an initial implementation plan and

schedule and stated the feasibility of the implementation.

III. Problem Analysis

A. CATWOE ANALYSIS

The CATWOE analysis was used to help define and identify the problem with voter satisfaction

and the voting system. It provided necessary information to see the big picture and understand what is

important.

Customers: The customers benefit from, or are victims of, the metamorphosis of the system. The voters

are the customers in the voting system and they are the ones that need to be addressed and satisfied

during this transformation process. The voters will be using the new voting system and we need to

make sure that the system is easy to use, reliable, secure, and protects the voter’s privacy. The FEC is an

indirect customer that will be overseeing the new voting system and will be held responsible if voters’

needs are not met.

Actors: The actors of the system carry out the activities of and support the system. The administrators

(booth workers, technicians, etc.) are responsible for assisting voters and supplying information about

the voting process, maintaining the voting system, and making sure the election process is followed

according to regulations. The voters use the system to cast their votes. Government regulators ensure

that everyone involved in the election process and the process itself follow the regulations set forth by

Federal and state governments.

Transformation: Transformation describes the current and future states of various processes within the

system. The voting system will be converted from a manual, inefficient, expensive, error-prone, non-

standardized, and confusing process to an automated, efficient, less expensive, less error-prone,

standardized, clear process.



5

World View: The world view provides insight from people seeing the system from the outside. We have

collected six distinct world views. Public perception is that modernized technology will streamline and

enhance voting processes. The FEC believes that voter turnout may increase due to an improved voting

process. Various media outlets think that a standardized voting process may increase the efficiency and

timeliness of polling results. Congress feels that an automated voting system will save tax dollars. The

Environmental Protection Agency (EPA) will fully support a voting system that uses modernized

technology because they perceive a decrease in the current carbon footprint.

Owner: The owner is the person or entity that owns the process and is crucial to its success or failure.

The FEC (with a representative from each state) is in charge of overseeing the transformation of the

voting system; provides the funding for designing, building, and implementing the voting system; and

makes sure the voter’s satisfaction is considered throughout the transformation process.

Environment Constraints: The environmental constraints are the factors that bind the system. We

have found several environmental constraints for the modern voting system. The cost of implementing

technology for the voting system is constrained by federal funding. The modernization of the voting

system is bound by the technology currently available. The placement of polling centers are constrained

by geographic areas that can supply the necessary resources for administering polling centers. Weather

can cause power failures and deter voters from going out and voting. Federal and state governments, as

well as voters, could undergo a paradigm shift in how they view the problems and the importance of

fixing the problems in the voting system. The voting system is heavily confined by the amount of

government funding Congress will allot for the new system.

B. OBJECTIVES

As stated in Section 1, our main objective is to be able to increase voter satisfaction by over

25%. That objective was then broken down further into seven objectives. Those objectives were brokendown further until we were satisfied with the overall set of lowest-level objectives that the system must

accomplish. For each lowest-level objective, a metric and a target were assigned to measure the success

or failure of meeting each objective. These objectives were used to generate the requirements of the

voting system and were used to assess the functional elements for building the architectures. The full

objectives tree is shown in Figure 1 in the appendix.

C. CONSTRAINTS

The following are primary constraints of the development of our design of the voting system:

The initial design needed to be finished by July 18th, 2011 We were confined by the currently available technology to develop the system

The federal funding for the project is approved by Congress

The amount of federal funding approved for the project may limit the scope

The new voting system must be implemented by the 2016 elections

Additional constraints are listed in the CATWOE section.



6

IV. Requirements Analysis

A. REQUIREMENTS DEVELOPMENT

The requirements analysis phase of the project describes what the system will do. The

development of requirements laid the foundation for the architecture of thei VOTE system. It was an

arduous task that required an immense amount of effort and team focus. The process also helped

establish the system boundaries into which the i VOTE system would be developed. The continued

dialogue with the FEC was necessary to ensure that changes or refinements were captured.

Requirements were developed from the objectives and their associated targets, through

functional decomposition (Figure 2), creation of multiple use cases, and brainstorming sessions.

Collaborative brainstorming provided freedom for the flow of ideas to allow the team to explore

alternatives and easily eliminate ideas that were not relevant. Group 2 developed a detailed list of

requirements that evolved and became more and more refined over time. The team wrotei VOTE

requirements in a clear and concise manner so that the system can be properly designed to meet FEC

needs. We made significant efforts to ensure that each requirement incorporated a performance

measure to validate the system.9

For traceability, the team came up with its own unique identifier schema for the requirements.

The identification schema is constructed from the system name (i VOTE), the version number, the

requirement number (within its type), and the requirement type. An example identifier for a

requirement is “iVOTE-1.0-001-F”. The purpose of this unique numbering is to trace any requirement

throughout all documents associated with the i VOTE system development. Its use supports continuous

life-cycle management, correlation with the functional decomposition, and interpretation or recognition

of sub-systems components. The full table of requirements is shown in Figure 3.

B. REQUIREMENTS DERIVATION

Articulate, concise requirements were the vehicle that laid out the entire infrastructure for the

system architecture and provided the input to operational, functional and physical views of the i VOTE

system. Requirements analysis enabled sound design and developmental efforts. Full i VOTE system

capabilities were derived as a result of requirements analysis. There is a reconciliation phase of the

requirements analysis that ensures support of the customer’s expectations. The team established a

requirements document that categorized them by their type and unique identifier. We also created a

Functional Allocation Matrix that maps the lowest-level functions from the functional decomposition

diagram to the requirements to show that we have captured the necessary functionality of the system.10

Capturing solid requirements is a difficult process and requires continuous refinement

throughout the evolution of the systems engineering process. It is one of the most critical and

challenging aspects of systems development because of the need to include major stakeholders in the

process to make sure their interests are captured. With good requirements, the entire system

development is clearer while making the functional specification feasible. The framework for thei VOTE

system was fabricated from the establishment of well written, concise requirements. A Function



7

Allocation Matrix (Figure 4) was created to show how all the functions from the functional

decomposition are mapped to the requirements.

V. Analysis of Alternatives

A. IDENTIFY ALTERNATIVES

After we developed our requirements, we found components that would satisfy them and

perform the functions in the functional decomposition. We first created component categories (voting

and registration interface, identification/authentication, and security) and then identified components

that would fit into those categories to potentially be used in the set of alternative architectures. Next,

we formed a hierarchy diagram depicting the component categories and associated components. Figure

5 in the appendix shows the hierarchy diagram used for the architecture development. In order to

depict how we eliminated various components from the possible choices, yellow callouts, along with red

slash lines, were used. Each callout states how each of the eliminated components failed to meet the

target of specific objectives. After we went through this process, we developed our architectures based

on the available choices that were left. We defined three final architectures (known as A-1, A-2, and A-

3) as shown in Figure 6 that became the basis for our analysis of alternatives.

B. RISK ANALYSIS AND MITIGATION

i VOTE system risks were researched and identified through brainstorming sessions. As a result

of the collaborations, thirty-seven risks were identified. They were compiled and entered into the Mitre

Risk Matrix software tool for consolidation and weighting quantification. The Risk Matrix software was

used in the basic mode, and the following columns of information were used in our analysis13

:

1) Risk Number – an assigned integer value

2) Related Risk Number – other risks that are affected

3) Risk – risk description

4) Impact of Risk – (C=Critical, S=Severe, Mo=Moderate, Mi=Minor, N=Negligible)

5) Po - Probability of Occurrence from 0 to 100%

6) Borda Rank – provided by the Risk Matrix Software

7) R – Borda ranking as calculated by the Risk Matrix Software

8) Manage/Mitigate – a strategy of mitigation provided through group consensus

The thirty-seven risks were applicable for the three reduced architectures that we have evolved.

The Risk Matrix Software was applied independently to each architecture using different percentage

values for the probability of occurrence. The results were then sorted by Borda Rank to derive each

architecture’s specific Borda ranking.

Associated i VOTE risks were a major part of the analysis of alternatives in order to determine

which architectural design to select architectural design A-2 as our final solution. As architectures were

independently analyzed for risk, information security ranked considerably higher as an area of concern

for the i VOTE system. For example, in architecture A-1, information security related risks appeared in



8

six of the top ten riskiest consequences of the voting system. This was also true of architectures A-2 and

A-3, leading our team to conclude that information security is the greatest overall risk to the i VOTE

system.

Mitigation strategies were crafted to each specific risk item to reduce the impact of negative

consequences to our system, should a risk occur. The “percentage of occurrence” value for each riskwas derived from expert judgment. Noting that information security was the biggest risk to the i VOTE

system, the team composed a strategy to mitigate the risk by creating an information security policy,

performing a threat and vulnerability assessment, and applying safeguards (such as encryption, access

controls, system auditing and logging, redundancy, etc.). A risk mitigation plan will be drafted and

approved by the FEC, and subsequently utilized to manage risks. The risk mitigation plan will have to be

monitored and revised as appropriate to align with project evolution. The full risk table is depicted in

Figure 7.

C. TECHNOLOGICAL AND ECONOMIC FEASIBILITY AND ANALYSIS

Many options and alternatives were explored by our engineering team. To implement anddeploy within the allotted budget constraints and project schedule, we composed our technical and

economic analysis to ensure feasibility and cost effectiveness of the proposed i VOTE system.

While undergoing the design phase, selection of a surefire architecture was essential. Our

engineering team undertook many technological options via market leading vendor research and

analysis, subject matter experts, architectural designs, and potential geographic locations of the data

center deployment into consideration for the selection of our architecture. This analysis also

contributed to the selection of technical components to procure and integrate into the voting system.3

Ultimately, cost and feasibility determined the architecture that was chosen to design and

develop. Each proposed architecture provides functionality that supports identification and

authentication of a given user and network security for the voting system. Architecture 1 (A-1),

Architecture 2 (A-2), and Architecture 3 (A-3) all possessed web application capabilities; however, only

A-2 and A-3 provided web services and a Smartphone application. A-1 was the least costly option to

design and develop, but did not provide the aggregate value needed to cover all identified factors

captured in the objectives and requirements.11

When analyzing the comparison of final costs associated to build A-2 and A-3 respectively, A-2

proved to be the best value overall as a result of A-3’s USB authentication devices which would have

exceeded the proposed budget. Total cost figures across architectural designs consisting of software

development and information security can be found in Figure 8.12

Other economic cost considerations taken were in the selection of the location of where to host

the data center containing virtualized servers. It should also be noted that all costs were found through

market research with the exception of specific costs for web services, web application, and intrusion

protection systems for the data center.14

The virtualized servers were found to decrease data center

costs by 30% compared to completely hardware based servers. Housing the actual host datacenter

proved to be most cost effective in the Midwestern states where cost of living and energy costs were

significantly lower than the costs associated in major market cities and states. Historic voting

mechanisms utilized more stationery and labor costs, while the proposed design interface eliminates

much of those costs by measuring the votes virtually. The modernized system as defined by A-2, is



9

estimated to reduce ‘Per Voter’ cost by 96.4%. This ‘Per Voter’ cost savings along with the overall

economic analysis are significant factors in gaining governmental support.15,16,17

D. SCORING ALTERNATIVES

The scoring of alternatives provides one way to find out which alternative would be best suited

to be the final solution for the i VOTE system. All of the objectives and their associated targets were

used as the evaluation criteria for the basis of the scoring. Using expert judgment, a value was assessed

for each criterion as to what a particular architecture would perform at for that criterion. In order to

score the alternatives, we first had to create a rating scale that would be used to quantify the criteria on

the same level. A scale of 1 to 9 was used (5-meets the target; 1-completely misses the target; 9-

completely exceeds the target) to rate each of the criteria based on the value each received using expert

judgment. A weight was then assessed for each criterion based on expert judgment and the FEC’s input.

The weight and rating were multiplied together to get a score for each criterion per architecture. The

scores for each architecture were then added together to get a composite score. Figure 9 shows the

Excel table that was used to calculate the scores. As shown in the figure, architecture A-2 scored the

highest which coincides with what the FEC decision makers deduced using a software application called

Accord (Accord allows multiple decision makers to assess criteria by stating how they feel each criterion

satisfied the target value and how certain they are of the assessment). The results from Accord are

shown in Figure 10. Based on the scoring, risk analysis, and economic analysis for the three

architectures, A-2 was selected as the i VOTE architecture.

E. SENSITIVITY ANALYSIS OF CRITERIA WEIGHTING

After scoring the architectures, sensitivity analysis was performed on the criteria weights to see

if a small change in the weights would cause a significant change in the final outcome. The FEC top five

most important criteria (Figure 11) were analyzed in pairs and the weights were traded off to see if the

final composite scores would change. A chart depicting this analysis in Figure 12 shows that none of the

weight trading seemed to affect the final result of the A-2 architecture scoring the highest.

The next step was to perform sensitivity analysis on the top five criteria versus several lowest-

weighted criteria. The chart in Figure 13 shows again that none of the weight trading seemed to affect

the final result of the A-2 architecture scoring the highest. Based on this analysis, the weights of the

criteria were not modified from the original weighting schema.

VI. Architecture Solution

A. DETAILED DESCRIPTION OF SOLUTION

A Function Component Matrix (Figure 14) was created to show how the lowest-level functions

from the functional decomposition can be mapped to the components of architecture A-2. The OV-1

shown in Figure 15 depicts the system (based on the A-2 architecture) in two main sections. The upper

part of the diagram depicts methods for the voter to cast their vote. These methods include voting via



10

the Internet, smart phone, and polling centers. The lower portion of the diagram depicts the back end of

the system: Security, Authentication, Registration, and the Central Voting System.

The upper left portion of the diagram depicts the polling centers. Polling centers in the i VOTE

system are operated similarly to current polling centers. A registered voter would enter the polling

booth, log in to the system with their credentials, and cast their vote. Upon exit, the voter may be askedto participate in a voting survey.

The Remote Voting node is where the paradigm shift in the traditional voting system will occur.

A web based voting interface, built on Service Oriented Architecture (SOA) principles, allows the voter to

cast a vote from any web-enabled device: personal computer, tablet, smart phone, etc. This allows the

voter to vote from non-traditional polling places, at their convenience, helping to alleviate the waiting

time at the polling centers. Human factorization will have to be taken into account when building the

interfaces to make them intuitive and easy to use for the voters. Remote voting increases the

satisfaction of both the remote voter (by not having to wait in line) and the polling center voter (by

decreasing the crowds at the polling center). As the remote voting concept is increasingly accepted by

the voting public, the number of polling centers is anticipated to decrease.

The middle and lower section of the OV-1 diagram depicts the central part of the i VOTE system.

The registration process takes place prior to the election date. The i VOTE system will provide a national

registration web interface in addition to the current registration process: registering with Department of

Motor Vehicle offices and local election boards. The i VOTE system will store the registration

information.

The interfaces between the Registration sub-system and the registration input methods utilize

the Network security in place: AES encryption, Medium Security Firewall and Maximum security IPS.

When the voter is ready to vote on Election Day, they will also need to interface with the Registrationsub-system to authenticate as a registered voter and ensure that they are allowed one vote only. The

authentication process uses the same network security process as the registration process. The

authentication process also uses a triple user identification method to minimize fraud and bot access:

Username/Password; PIN; and CAPTCHA – a challenge response test used to help ensure the response is

generated by a person. (CAPTCHA WIKI)

Once a voter is authenticated, a ballot will be presented for the proper jurisdiction. This ballot

will include candidates for national, state, and local offices and referendums that are stored in the

“Candidates and Referendums” database. After the voter makes selections,a confirmation page will

then be presented that the voter must either agree to, or return back to the ballot.

Once the voter agrees to the confirmation page, the vote will be recorded in the “Voting

Results” database in the National Data Center (NDC) of the Central Voting System node. The three

databases housed in the Central Voting System are kept separate for voter confidentiality as well as

security; issues in one database will not affect another database. As votes are cast, the NDC compiles,

validates, and reports them. Interim and final results are reported to media outlets and other official

sources. Final results are also sent to local election boards, state boards, and the FEC.



11

These nodes are made possible with the extent that the Internet has been adopted. The remote

voting system is dependent on Internet connections for the voters to cast their votes and have them

registered at the NDC. All data transfer between sites is via an Advanced Encryption Standard (AES)

encrypted data link (https protocol). AES encryption was chosen over DES and 3DES because of speed

and performance factors discussed in the alternatives section.

B. VERIFICATION AND VALIDATION

This Verification and Validation (V&V) Plan is the systematic strategy to test the i VOTE system to

ensure compliance with the design specification, objectives, and requirements. Tests may consist of a

simple pass/fail visual inspection, or be comprised of complex statistical figures which must meet or

exceed requirements in order to be declared successful. The following details the responsible quality

assurance parties and V&V focus areas.

Federal Election Committee (FEC): The FEC is responsible for the verification and acceptance of

the design deliverables. Each milestone deliverable must be inspected and given a pass or fail

designation via consensus vote. In addition, the FEC must perform process improvement verification by

validating goals to be reached after each i VOTE project phase.

One method for validation will be an i VOTE provided queue simulation program (Figure 23). This

program would have the ability to produce polling center statistics such as: Average Number of Voters,

Average Number of Voters Waiting in Line to Vote, Average Wait Time, and Average Voting Time. This

verification could be used to ensure that the requirements are being met, and to validate the

improvements made by the i VOTE system; such as relieving polling center congestion.

Voter Focus Group (VFG): The VFG is a randomly selected group of voters that have agreed to

participate in our process improvement initiative. These members will conduct product acceptance

validation such as customer satisfaction surveys, functional requirement and regression testing, and

validation of ballot submissions. The customer satisfaction surveys will consist of qualitative categories

like user interface ease of use, information presentation effectiveness, effectiveness of help

information, time management efficiency, as well as their overall voting experience. The VFG will also

be asked to step through each section of the application to ensure that all functions are properly

implemented according to requirements, and verify that their input data has been captured correctly

within our database report.

iVOTE Team: The i VOTE team will validate the date in the National Data Center (NDC) against

the local databases to ensure consistency, validate all functional decomposition items are implemented

and working properly as independent components as well as integrated with disparate components or

subsystems, and validate network statistics and system efficiency against our requirements.

C. IMPLEMENTATION PLAN

Factors to be considered for a successful implementation were grouped into three categories:

highest probability of failure, necessary resources, and likely obstacles.



12

The two items with the highest probability of failure identified are obtaining full federal funding

and handling high volumes of simultaneous ballot submissions. Obtaining federal funding is potentially

challenging as the U.S. economy is presently in a recession. The i VOTE system’s implementation costs

will be offset by lower operating costs and projected profits from selling access rights to early analysis

firms (such as CNN and MSNBC). This is essential to garnering funds for the i VOTE system.

Necessary resources are funding, smart-phone licenses, data storage facilities, DMV registered

voter records, software licenses, hardware acquisition, and contractors to develop the system. As

discussed earlier, funding is the main resource for implementation. Acquiring smart phone licenses to

deploy our i VOTE software is also crucial for system functionality. In order to satisfy the goal of

providing multiple voting options, smart-phone voting has been identified within our architecture

solution as feasible and desirable. DMV registered voter records is the primary means for efficiently and

effectively compiling the i VOTE user database upon initial implementation. Also, contractors, software,

and hardware must be procured in order to ultimately construct the system.

Finally, likely obstacles will include: funding approval, throughput management, and data

protection advancements. Funding has been discussed at length within this plan and remains a key focus

area for implementation success. Throughput management must be monitored because of the large

amount of voters that potentially could bring down the system by casting simultaneous ballots. Aside

from funding, data protection is the second most likely obstacle that will need to be closely tracked in

order to allow for successful implementation. If the i VOTE system is perceived to have insufficient

safeguards for the protection of sensitive information, our project will be in jeopardy.

The i VOTE implementation schedule shown in Figure 24 follows the engineering development of

the system. The Initial System Design is followed by the Critical Design. Once the Engineering team

completes the Critical Design and successfully completes the Critical Design Review, the Developers take

over to create the prototype system. The prototype is a small scale test of the system to ensure the

design is feasible. A successful prototype will lead to the Implementation phase of the project.

Implementation has two phases: Trial System and Full Implementation.

The Trial System is a small scale implementation where the system is deployed to several voting

jurisdictions. With this small-scale deployment, i VOTE testers will deploy with the system to ensure it is

implemented properly. This phase will have to include focus groups to provide feedback on the usability

of the system as well as other metrics being tracked for the system. The deployment team will be called

on to ensure that the full size system is built and the system is deployed to all jurisdictions. The

deployment team will also develop a training plan and provide training to local jurisdictions. Once the

Full Implementation phase is complete, the i VOTE system is ready for operation. The i VOTE system will

transition to Operations and Maintenance. System disposal is a continuous cycle within the Operations

and Maintenance phase. As systems are determined not to be economically repairable, they will be

replaced. A detailed analysis of the systems deployed will determine the typical lifecycle of the voting

machines. The schedule, as it is currently, has the full implementation completed in the third quarter of

Calendar Year 2015. The system charter calls for this system to be implemented by the 2016 national

election – this gives us approximately twelve months of slack time in this schedule.



13

Essentially, the i VOTE team has constructed a detailed implementation schedule which will

provide the project team with a roadmap to bridge the gap from the design phase to the operational

maintenance phase. The highest level attributes of the implementation schedule consist of an initial

system design, system review, critical design, prototype iterations, initial implementation supported by

a trial testing system, and ultimately concluding with our full implementation of the system. Along with

the identification of the scheduled tasks, we have also designated the appropriate personnel to execute

and be accountable for the task completion within our implementation schedule as a whole.

VII. Conclusion

The objective of our analysis was to increase voter satisfaction by 25%. Group 2 has

demonstrated the use of the systems engineering process to modernize and standardize the voting

system. By doing so, we have ensured that the voting system is more efficient, less error-prone, and

easier to use, therefore increasing voter satisfaction. We have also shown that a modernized voting

system will positively impact the environment by reducing the use of administrative resources such as

manpower and stationery.

Through our economic analysis, we have stated how virtualization of servers can reduce costs by

up to 30% and also decrease the carbon footprint of the new i VOTE system by using less power and

space. Even though our risk analysis revealed that information security is clearly our biggest risk, it can

be well managed and mitigated through the use of our strong security policy, a thorough threat and

vulnerability assessment, and the application of safeguards; such as encryption and network security

appliances. This is only the beginning for the modernized voting system.

In the future, additional analysis will need to be completed to ensure that the i VOTE system

performs at the optimal levels expected in the requirements and objectives. Throughout the maturation

of i VOTE system development, refinement of requirements, additional functional elements, futureexpansion, composition of an extensive cost model, provision of greater levels of detail for the

established architecture depictions, and thorough testing procedures are tools that the team will utilize

to continuously enhance the modernized voting system.

Group 2 will need to further analyze the registration process, verify voter acceptance of the new

system, and state how to maintain and upgrade the system throughout its lifecycle. Additionally, the

team will need to continually update the FEC on progress as the system is built and implemented to

secure congressional funding for the project. We are considering utilizing the National Security Agency

(NSA), and other national law enforcement and intelligence agencies to monitor security during

elections which should reduce risk and increase voter confidence. Expanding the elections from one dayto three days will also increase the efficiency of the system, thus increase voter satisfaction as well. We

strongly believe that this new modernized voting system that we have conceptualized during this

Capstone course can truly come to fruition if it is planned, designed, and implemented properly. Voter

satisfaction will increase, as well as voter turnout, which will provide a more accurate reflection of the

people of the United States.



14

VIII. References

1[WWWdocument],http://www.pewcenteronthestates.org/uploadedFiles/MN_WA_recounts_report.pd

f 3 JUL 2011.

2[WWWdocument],http://www.pewcenteronthestates.org/uploadedFiles/Election%20Preview%20FINA

L.pdf 21OCT 2008.

3 The Real Cost of Voter Registration: An Oregon Case Study (Washington, DC: Pew Center on the States,

March 2010); http://www.pewcenteronthestates.org/report_detail.aspx?id=56478.

4 “Maintenance of State Voter Registration Databases: A Review of Relevant Policies and Procedures”

(Washington, DC: National Association of Secretaries of State, September 2009), 4 –11;

http://nass.org/index.php?option=com_docman&task=doc_download&gid=792.

5 Caltech/MIT Voting Technology Project, Voting: What Is, What Could Be, July 1, 2001, 51;

http://www.vote.caltech.edu/drupal/node/10.

6 Barreto, Glaser, and MacDonald, Online Voter Registration (OLVR) Systems in Arizona and Washington,

93. In fact, approximately 90 percent of all online registrations cost nothing to process, due to an

absolute match with data in the motor vehicles database. The other 10 percent required some follow-

up, which cost on average 33 cents per form, leading to an average cost of 3 cents for all online

registrations.

7 [WWWdocument], http://www.eac.gov.

8 Improving State Voter Registration Databases: Final Report (Washington, DC: National Research

Council of the National Academies, 2009) 45;

http://books.nap.edu/openbook.php?record_id=12788&page=R1.

9 NYS Project Management Guidebook, Section III:2 System Requirements Analysis;

www.cio.ny.gov/pmmp/guidebook2/SystemReq.pdf,Thursday, July 14, 2011

10 Presentation, EMSE 297 Problems in Engineering Management and Systems Engineering, Session #3;

A Little Primer on Writing Good Requirements, Dr. Tom Holzer

11 http://osxdaily.com/2010/09/07/iphone-development-costs/

12 http://www.vmware.com/solutions/cost-savings/index.html

13 Software Source: The MITRE Corporation, Risk Matrix Software Version 2.2 November 1999

14 [WWWdocument], http://infosecuritystore.com/aladdin-etoken-pro.html

15 [WWWdocument], http://storagemojo.com/2008/10/12/building-a-18-exabyte-data-center/

16 [WWWdocument],http://www.infobahn.com/research-information.htm

http://www.pewcenteronthestates.org/uploadedFiles/MN_WA_recounts_report.pdf


http://books.nap.edu/openbook.php?record_id=12788&page=R1

http://c/Documents%20and%20Settings/sharmaat/Local%20Settings/Temporary%20Internet%20Files/Content.Outlook/2CN1NJBL/www.cio.ny.gov/pmmp/guidebook2/SystemReq.pdf

http://www.vmware.com/solutions/cost-savings/index.html


http://infosecuritystore.com/aladdin-etoken-pro.html


http://storagemojo.com/2008/10/12/building-a-18-exabyte-data-center/


http://www.infobahn.com/research-information.htm

http://www.infobahn.com/research-information.htm




http://c/Documents%20and%20Settings/sharmaat/Local%20Settings/Temporary%20Internet%20Files/Content.Outlook/2CN1NJBL/www.cio.ny.gov/pmmp/guidebook2/SystemReq.pdf

http://books.nap.edu/openbook.php?record_id=12788&page=R1





15

17 [WWWdocument],http://www.kaycircle.com/mt-What-is-the-Average-Cost-of-a-Firewall-Average-

Firewall-Price

http://www.kaycircle.com/mt-What-is-the-Average-Cost-of-a-Firewall-Average-Firewall-Price






16

IX. Appendix

Figure 1 - Objectives Tree



17

Figure2 - Functional Decomposition



18

Unique Identifier* Requirement Type

iVOTE-1.0-001-F The voting system shall allow at least 85% of voters to vote remotely Functional

iVOTE-1.0-002-F The voting system shall provide voters at least 3 different voting methods Functional

iVOTE-1.0-003-F The voting system shall report official polling data within 8 hours of the last poll being closed Functional

iVOTE-1.0-004-F The voting system shall allow at least 85% of voters to remotely register to vote Functional

iVOTE-1.0-005-F The voting system shall allow 100% of the voters to change their choices before casting their final vote FunctionaliVOTE-1.0-006-F The voting system shall automatically capture and tabulate votes with a rate of at least 100 ms per 100,000 votes Functional

iVOTE-1.0-007-F The voting system shall protect the voter’s privacy by having less than one unauthorized disclosure per 1,000,000 voters Functional

iVOTE-1.0-008-F The voting system shall secure all voting information by having less than one unauthorized disclosure per 1,000,000 voters Functional

iVOTE-1.0-009-F The voting system shall secure the voting environment by having less than one unauthorized disclosure per 1,000,000

voters

Functional

iVOTE-1.0-010-F The voting system shall allow a user to cast one vote and only one vote per election Functional

iVOTE-1.0-011-F The voting system shall make official voting results available within 8 hours Functional

iVOTE-1.0-012-F The voting system shall accept “write-in” candidates with at least 98% accuracy Functional

iVOTE-1.0-013-F The voting system shall validate the identity of the voter with at least 99.9% accuracy Functional

iVOTE-1.0-014-F The voting system shall authenticate the voter based on unique information that only the voter knows with at least 99.9%

accuracy

Functional

iVOTE-1.0-015-F The voting system shall verify voter registration with at least 99.5% accuracy FunctionaliVOTE-1.0-016-F The voting system shall store all voting information with an integrity failure rate of less than 1.5% Functional

iVOTE-1.0-017-F The voting system shall backup all voting information resulting in 100% redundancy of the information Functional

iVOTE-1.0-018-F The voting system shall authenticate the voter with at least a two-factor authentication method Functional

iVOTE-1.0-001-P The voting system shall increase voter satisfaction by more than 25% Performance

iVOTE-1.0-002-P The voting system shall decrease the number of voters that go to a physical polling station by at least 30% Performance

iVOTE-1.0-003-P The voting system shall reduce manual recounts by at least 75% Performance

iVOTE-1.0-004-P The voting system shall decrease the amount of time voters spend at polling centers by at least 20% Performance

iVOTE-1.0-005-P The voting system shall decrease the amount of time voters spend voting by at least 25% Performance

iVOTE-1.0-006-P The voting system shall decrease the number of absentee ballots by at least 80% Performance

iVOTE-1.0-007-P The voting system shall increase the ease of use to vote by an average voter rating of at least 7 out of 10 Performance

iVOTE-1.0-008-P The voting system shall increase efficiency in the voting process by at least 40% Performance

iVOTE-1.0-009-P The voting system shall handle 50% of the voters casting ballots simultaneously Performance

iVOTE-1.0-010-P The voting system shall capture votes accurately with at least 99% accuracy Performance

iVOTE-1.0-001-In The voting system shall accommodate at least 99% of disabled voters Interface

iVOTE-1.0-002-In The voting system shall provide the user access to real-time candidate, legislative, and help information that requires an

average voter rating of at least 8 out of 10

Interface

iVOTE-1.0-001-D The voting system shall use COTS (Commercial Off-The-Shelf) hardware that has a Total Readiness Level (TRL) of at least 8 Design

iVOTE-1.0-002-D The voting system shall use modern technology that has a TRL of at least 7 Design

iVOTE-1.0-003-D The voting system shall use no more than 70% of newly developed customized technology Design

iVOTE-1.0-001-O The voting system shall reduce the number of polling station facilities by at least 30% Operational

iVOTE-1.0-002-O The voting system shall reduce the amount of polling station staff by at least 35% Operational

iVOTE-1.0-001-I The voting system shall maintain a reliability of at least 98.5% -ilities

iVOTE-1.0-002-I The voting system shall maintain all voting information making it available at least 97% of the time when needed -ilitiesiVOTE-1.0-001-C The voting system shall operate by the 2016 election and maintain a Schedule Performance Index (SPI) >= .96 for each

project milestone

Constraint

iVOTE-1.0-002-C The voting system design shall stay within the five million dollar budget and maintain a CPI >= .95 for each project

milestone

Constraint

iVOTE-1.0-003-C The voting system shall reduce the amount of non-electronic administrative resources (paper, pencils, brochures, etc.) by

at least 50%

Constraint

iVOTE-1.0-004-C The voting system shall reduce maintenance costs by at least 40% Constraint

Figure 3 - Requirements Table



19

Figure 4 - Function Allocation Matrix



20

Figure 5 - Component Hierarchy Diagram

Figure 6 - Reduced Architectures



Figure 7 - Risk Matrix



23

Figure 8 - Economic Analysis

Figure 9 – Architecture Scoring



24

Figure 10 – Accord Results from FEC

Figure 11 - Function Component Matrix



25

Figure 12 – FEC Top 5 Criteria and Weights

Figure 13 - Sensitivity Analysis between Two Top 5 Criteria

Figure 14 - Sensitivity Analysis between One Top 5 Criterion and Lowest-weighted Objective

Baseline

Baseline



26

Figure 15 - OV-1 High Level Operational Concept Diagram



27

Figure 16 - AV-1 Overview and Summary Information Product

Figure 17 - OV-2 Operational Node Connectivity Diagram

•Architecture Project

Identification

– Assumptions andConstraints: All voters can

get access to the Internet;

constrained by



28

Figure 18 - OV-3 Operational Information Exchange Matrix

Figure 19 - OV-5 Operational Activity Model: Casting and Processing a Vote



29

Figure 20 - SV-1 Systems and Interfaces Diagram

Figure 21 - SV-4a Data Flow Diagram for Capture Vote



30

Figure 22 -SV-5b System Functions-to-Capabilities Traceability Matrix

Figure 23 - Quality Assurance

FEC Validation Tool: Obj_1: To have voters spend 20% less time at polling cen

Obj_2: To be able to allow voters to spend 25% less time

Pre-i VOTE Post-i



Figure 24 - iVOTE Implementation Schedule