Successfully reported this slideshow.

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

E voting

  1. 1. ISSR E-Voting A project submitted in partial fulfillment of the requirements for the degree of Diploma of Information System Project team: Maged Mohamed Farid Elwakil Abd Elmenaem Zeinhom Abd Elmaksoud Wesam Rabeh Ali ELAgamy Rania ElEasawy Abd Elreheem Amal hassan Ali Talkhan Mohamed Talaat Rashed Shalash Under supervision: Dr. Doaa Nabil Cairo 2011
  2. 2. Document Version History Ver. No. Ver. Date Prepared By Reviewed By Description Wesam Rabeh Mohamed Shalash Amal Talkhan Initial Document and 1.0.0 12-4-2011 Rania Zora scope Abd Elmonem Maged Elwakil Mohamed Shalash 1.0.1 14-4-2011 Requirement definition Maged Elwakil 1.0.2 17-4-2011 Maged Elwakil Dr. Doaa Nabil Wesam Rabeh Use cases and analysis 1.2.0 4-5-2011 Mohamed Shalash documents Maged Elwakil 1.3.0 7-5-2011 Maged Elwakil Design diagrams Wesam Rabeh Mohamed Shalash Amal Talkhan 1.4.0 11-5-2011 Dr.Doaa Nabile Review Rania Zora Abd Elmonem Maged Elwakil Component, deployment, 1.5.0 Maged Elwakil and network infrastructure diagrams Mohamed Shalash 1.6.0 2-6-2011 Rania Zora Application Interfaces Maged Elwakil Wesam Rabeh Mohamed Shalash Amal Talkhan 2.0.0 15-6-2011 Dr. Doaa Nabil Test plan Rania Zora Abd Elmonem Maged Elwakil Mohamed Shalash 2.0.1 18-6-2011 Enhancement Maged Elwakil Mohamed Shalash Final and approved 2.1.1 1-7-2011 Dr. Doaa Nabil Maged Elwakil document Page 2
  3. 3. Acknowledgement On the behalf of the Institute of Statistical Studies and Research, Cairo University, and on our own behalf, we would like to express our profound thanks and great attitude to all those respectable Professors in capacity of Dr. DOAA NABIL who guided us through the preparation of this project. We would also appreciate the 25th January revolution and its spirit which inspired the Egyptians to move towards the modernization, the establishment and the democracy of future EGYPT. Page 3
  4. 4. Abstract Elections allow the populace to choose their representatives and express their preferences for how they will be governed. Naturally, the integrity of the election process is fundamental to the integrity of democracy itself. The election system must be sufficiently robust to withstand a variety of fraudulent behaviors and must be sufficiently transparent and comprehensible that voters and candidates can accept the results of an election. Unsurprisingly, history is littered with examples of elections being manipulated in order to influence their outcome. The design of a “good” voting system, whether electronic or using traditional paper ballots or mechanical devices must satisfy a number of sometimes competing criteria. The anonymity of a voter’s ballot must be preserved, both to guarantee the voter’s safety when voting against a malevolent candidate, and to guarantee that voters have no evidence that proves which candidates received their votes. The existence of such evidence would allow votes to be purchased by a candidate. The voting system must also be tamper-resistant to thwart a wide range of attacks, including ballot stuffing by voters and incorrect tallying by insiders. Another factor is the importance of human factors. A voting system must be comprehensible to and usable by the entire voting population, regardless of age, infirmity, or disability. Providing accessibility to such a diverse population is an important engineering problem and one where, if other security is done well, electronic voting could be a great improvement over current paper systems. Flaws in any of these aspects of a voting system, however, can lead to indecisive or incorrect election results. There have been several studies on using computer technologies to improve elections. These studies caution against the risks of moving too quickly to adopt electronic voting machines because of the software engineering challenges, insider threats, network vulnerabilities, and the challenges of auditing. Page 4
  5. 5. Table of Contents Acknowledgement..........................................................................................................3 1.1 Introduction:.............................................................................................................9 1.2 Problem definition:.................................................................................................10 1.3 Glossary & Key terms............................................................................................10 1.4 Goals and Objectives .............................................................................................11 1.5 Project Scope:.........................................................................................................11 1.6 E-Voting Process Framework................................................................................12 1.7 Background research..............................................................................................13 Documented problems.......................................................................................................13 2.1 Methodologies........................................................................................................19 Object Oriented Programming............................................................................................19 Design Patterns..................................................................................................................24 ECC Pattern....................................................................................................................24 Adaptor pattern............................................................................................................25 Three-tier architecture.......................................................................................................25 Web Application................................................................................................................27 Distributed Data Base.........................................................................................................28 2.2 Feasibility Analysis:-.............................................................................................32 SWOT/PEST Analysis...........................................................................................................32 Strengths.........................................................................................................................32 Opportunities..................................................................................................................33 Weaknesses....................................................................................................................34 Threats............................................................................................................................34 2.3 Major Identified Risks...........................................................................................37 2.4 Requirement specification:-..................................................................................38 Functional Requirements:...................................................................................................38 B) Non-Functional Requirements:...................................................................................39 Security Requirements...............................................................................................39 2.5 Domain Model.......................................................................................................42 2.6 Use Cases...............................................................................................................43 Manage Judge/Admin-clerk............................................................................................43 Manage Precinct & Poll Station......................................................................................48 Manage Candidate..........................................................................................................53 Manage Voter.................................................................................................................58 Voting Process Use case .................................................................................................62 Reporting Use Case ........................................................................................................68 2.7 E-voting State Chart Diagram................................................................................72 Page 5
  6. 6. ......................................................................................................................................73 2.8 E-voting Activity Diagram.....................................................................................74 2.9 Package Diagram ..................................................................................................75 3.2 E-voting System Database ERD............................................................................78 3.5 Sequence Diagram.................................................................................................81 4.1 Component diagram...............................................................................................84 4.2 Deployment diagram..............................................................................................85 4.3 Network Infrastructure and VPN...........................................................................86 4.4 Application Interface..............................................................................................87 5.1 INTRODUCTION..................................................................................................91 5.1.1 Objectives..................................................................................................................91 5.1.2 Testing Strategy.........................................................................................................91 5.1.4 Reference Material....................................................................................................92 5.2 TEST ITEMS.........................................................................................................92 5.2.1 Program Modules......................................................................................................92 5.2.2 User Procedures.........................................................................................................94 5.2.3 Operator Procedures.................................................................................................94 5.3 Features to Be Tested.............................................................................................94 5.4. FEATURES NOT TO BE TESTED.....................................................................95 5.5. APPROACH.........................................................................................................95 5.5.2- Acceptance testing...................................................................................................96 Check all the links:..........................................................................................................96 Test forms in all pages: ..................................................................................................96 Cookies testing:...............................................................................................................97 Validate HTML/CSS.........................................................................................................97 Database testing.............................................................................................................97 Usability Testing..............................................................................................................98 Compatibility Testing:.....................................................................................................99 Performance testing:......................................................................................................99 Security Testing:...........................................................................................................101 GUI Test........................................................................................................................101 5.6. PASS / FAIL CRITERIA....................................................................................102 5.6.1 Suspension Criteria..................................................................................................102 5.7. Testing Process....................................................................................................103 5.7.1 Test Deliverables......................................................................................................103 5.7.2 Testing Tasks............................................................................................................103 5.7.3 Responsibilities........................................................................................................104 5.7.4 Resources.................................................................................................................104 Physical Resources:.......................................................................................................104 Human Resources:........................................................................................................104 Page 6
  7. 7. 5.7.5- Schedule.................................................................................................................104 5.8. Environmental Requirements..............................................................................105 5.8.1 Hardware.................................................................................................................105 Software 105 5.8.3 Risks and Assumptions.............................................................................................105 Conclusion and future work.......................................................................................106 References..................................................................................................................107 Page 7
  8. 8. Chapter One Introduction Page 8
  9. 9. 1.1 Introduction: Elections allow the populace to choose their representatives and express their preferences for how they will be governed. Naturally, the integrity of the election process is fundamental to the integrity of democracy itself. The election system must be sufficiently robust to withstand a variety of fraudulent behaviors and must be sufficiently transparent and comprehensible that voters and candidates can accept the results of an election. Unsurprisingly, history is littered with examples of elections being manipulated in order to influence their outcome. The design of a “good” voting system, whether electronic or using traditional paper ballots or mechanical devices must satisfy a number of sometimes competing criteria. The anonymity of a voter’s ballot must be preserved, both to guarantee the voter’s safety when voting against a malevolent candidate, and to guarantee that voters have no evidence that proves which candidates received their votes. The existence of such evidence would allow votes to be purchased by a candidate. The voting system must also be tamper-resistant to thwart a wide range of attacks, including ballot stuffing by voters and incorrect tallying by insiders. Another factor is the importance of human factors. A voting system must be comprehensible to and usable by the entire voting population, regardless of age, infirmity, or disability. Providing accessibility to such a diverse population is an important engineering problem and one where, if other security is done well, electronic voting could be a great improvement over current paper systems. Flaws in any of these aspects of a voting system, however, can lead to indecisive or incorrect election results. There have been several studies on using computer technologies to improve elections. These studies caution against the risks of moving too quickly to adopt electronic voting machines because of the software engineering challenges, insider threats, network vulnerabilities, and the challenges of auditing. Page 9
  10. 10. 1.2 Problem definition: Electronic voting systems are increasingly replacing the traditional paper-based voting systems. These systems can make the voting process more convenient and may therefore lead to improved turnout. Electronic recording and counting of votes could be faster, more accurate and less labor intensive. The goal of the E-Voting as a product is to automate the voting process, help in solving fraud problems, decreasing the voting time, and the process of counting. a strong relationship between the indicator from one side and the related parameters from the other side, so reaching the required data is really a big problem. 1.3 Glossary & Key terms a group of people living in a particular local area or a Community group of nations having common interests an employee who performs clerical work (e.g., keeps Clerks records or accounts) group of people who evaluate or judge a critical Judges opinion group of people electorate to make a decision or Voters express an opinion or group of citizens who has a legal right to vote a place where voters go to cast their votes in an Polling election or a venue established for the purpose of station/Committe polling and controlled by staff of the electoral e management body the place where people vote or an inquiry into public Polls opinion conducted by interviewing a random sample of people is the system by which a government records the vital Civil registry events of its citizens and residents someone who administers a business or someone Administrators who manages a government agency or department A person who is elected or nominee to a certain Candidate position or person seeking or being considered for some kind of position eg (to be elected to an office) An election is a formal decision -making process by Election which a population chooses an individual to hold public Page 10
  11. 11. 1.4 Goals and Objectives The e-voting system provides a voting service that allows people to vote from any poll site in the country electronically. This system encompasses legal, regulatory, behavioral, and sociological aspects of the current voting system, while adding additional convenience and security to the overall voting process. This system is designed to improve the current voting process in the following ways 1. Allow voters to vote from any poll site in the country without the use of absentee ballots 2. Reduce the number of legitimate votes not counted by reducing the number of over-votes, and eliminating vote tampering 3. Improve the registration process by allowing voters to check their registration status prior to voting and centralizing registration databases 4. Increase voter confidence and improve the voting experience 1.5 Project Scope: The system deals with how an e-vote process should be designed and implemented in order to comply with the democratic election principles and rights as well as to other human rights, which constitute the cornerstone of the international legal civilization. These issues are discussed in the light of the voting principles and rights of the users involved in an election process. The scope of the system is limited to the general public elections, and also includes every election or decision-making process, which takes place through voting. It extends also to (Internet or Intranet) polls without binding effects (if the latter - in view of their nature or their extent - could influence the public discourse in a given state or organization). The significance of the issues addressed herein is clearly manifested by the volume of debate that lately has begun on them, in many countries over the globe. This is understandable in view of the fact that technology usually moves at a pace faster than the legal system does. However, technological evolution should always be pursued as a means to improve human life as opposed to an end by itself. In this Page 11
  12. 12. respect, all technological development, in particular those directly or indirectly affecting fundamental principles should be carefully reviewed with an eye towards determining their contribution to the betterment of society. Despite the volume of material published to support this debate, including user requirements specifications, no consolidated view on the requirements deriving from constitutional and legal consideration is available. This is the main contribution of the system. The system is structured as follows: • The main issues associated with e-voting in presidential public election processes are discussed. • Requirements for an electronic voting system to be used in general elections. • Discusses requirements stemming from the democratic nature of the election process. The E-Voting system passes 3 major steps: 1- Pre-Voting (preparing administration, committee, candidates, and voters) 2- Voting (Voting process itself) 3- Post-Voting(Result counting and generating reports) 1.6 E-Voting Process Framework E-Voting process Framework 65535 Page 12
  13. 13. 1.7 Background research Polling place electronic voting or Internet voting examples have taken place in Australia, Belgium, Brazil, Canada, Estonia, the European Union, France, Germany, India, Ireland, Italy, the Netherlands, Norway, Romania, Switzerland, the United Kingdom, Venezuela, and the Philippines. Documented problems 1. the United States: Florida - A number of problems with voting systems in Florida since the 2000 Presidential election. - Punched cards received considerable notoriety in 2000 when their uneven use in Votomatic style systems in Florida was alleged to have affected the outcome of the U.S. presidential election. Invented by Joseph P. Harris, Votomatic was manufactured for a time under license by IBM. William Rouverol, who built the prototype and wrote patents, stated that after the patents expired in 1982, lower quality machines had appeared on the market. The machines used in Florida had five times as many errors as a true Votomatic, he said. - Punched-card-based voting systems, the Votomatic system in particular, use special cards where each possible hole is pre-scored, allowing perforations to be made by the voter pressing a stylus through a guide in the voting machine. A problem with this system is the incomplete punch; this can lead to a smaller hole than expected, or to a mere slit in the card, or to a mere dimple in the card, or to a hanging Chad. This technical problem was claimed by the Democratic Party to have influenced the 2000 U.S. presidential election in the state of Florida; critics claimed that punched card voting machines were primarily used in Democratic areas and that hundreds of ballots were not read properly or were disqualified due to incomplete punches, which allegedly tipped the vote in favor of George W. Bush over Al Gore. - Other punched card voting systems use a metal hole-punch mechanism that does not suffer nearly as much from this fault, although most states have eliminated punched card voting systems Page 13
  14. 14. of all types after the 2000 Florida experience. South Korea still predominantly uses punched card ballots. Virginia: - Fairfax County, Virginia, November 4, 2003. Some voters complained that they would cast their vote for a particular candidate and the indicator of that vote would go off shortly after. California: - The Premier Election Solutions (formerly Diebold Election Systems) TSx voting system disenfranchised many voters in Alameda and San Diego Counties during the March 2, 2004 California presidential primary due to non-functional voter card encoders. On April 30 California's secretary of state Kevin Shelley decertified all touch-screen machines and recommended criminal prosecution of Diebold Election Systems. The California Attorney- General decided against criminal prosecution, but subsequently joined a lawsuit against Diebold for fraudulent claims made to election officials. Diebold settled that lawsuit by paying $2.6 million On February 17, 2006 the California Secretary of State Bruce McPherson then recertified Diebold Election Systems DRE and Optical Scan Voting System. Napa County, California, March 2, 2004, an improperly calibrated mark sense scanner overlooked 6,692 absentee ballot votes. - Problems in the United States general elections, 2006: o During early voting in Miami, Hollywood and Fort Lauderdale, Florida in October 2006 three votes intended to be recorded for Democratic candidates were displaying as cast for Republican. Election officials attributed it to calibration errors in the touch screen of the voting system. o In Pennsylvania, a computer programming error forced some to cast paper ballots. In Indiana, 175 precincts also resorted to paper. Counties in those states also extended poll hours to make up for delays. o Cuyahoga County, Ohio: The Diebold computer server froze and stopped counting votes then the printers jammed so paper copies could not be retrieved for many votes and there was no way to be sure of the accuracy of the votes when the votes were being counted. o Walsenburg, Arkansas: The touch screen computer tallied zero votes for one mayoral candidate who confirmed that he Page 14
  15. 15. certainly voted for himself and therefore there would be a minimum of one vote, this is a case of disappearing votes on touch screen machines. The subsequent investigation found that the under vote was not caused by software error. Poor ballot design was widely acknowledged as the cause of the under vote. - Instances of faulty technology and security issues surrounding these machines were documented on August 1, 2001 in the Brennan Center at New York University Law School. NY University Law School released a report with more than 60 examples of e-voting machine failures in 26 states in 2004 and 2006. Examples included Spanish language ballots that were cast by voters but not counted in Sacramento in 2004. - 2008 United States Elections: o Virginia, Tennessee, and Texas: Touch screen voting machines flipped votes in early voting trials o Humboldt County, California: A security flaw erased 197 votes from the computer database. California top to bottom review. In May 2007, California Secretary of State Debra Bowen commissioned a "Top to Bottom review" of all electronic voting systems in the state. She engaged computer security experts led by the University of California to perform security evaluations of voting system source code as well as "red teams" running "worst case" Election Day scenarios attempting to identify vulnerabilities to tampering or error. The Top to Bottom review also included a comprehensive review of manufacturer documentation as well as a review of accessibility features and alternative language requirements. The end results of the tests were released in the four detailed Secretary of State August 3, 2007 resolutions (for Diebold Election Systems, Hart InterCivic, Sequoia Voting Systems and Elections Systems and Software, Inc.) and updated October 25, 2007 revised resolutions for Diebold and Sequoia voting systems. The security experts found significant security flaws in all of the manufacturers' voting systems, flaws that could allow a single non-expert to compromise an entire election. On August 3, 2007 Bowen decertified machines that were tested in her top to bottom view including the ES&S InkaVote machine, which was not included in the review because the company submitted it past the deadline for testing. The report issued July 27, 2007 was conducted by the expert "red team" attempting to detect the levels of technological vulnerability. Another report on August Page 15
  16. 16. 2, 2007 was conducted by a source code review team to detect flaws in voting system source code. Both reports found that three of the tested systems fell far short of the minimum requirements specified in the 2005 Voluntary Voting System Guidelines (VVSG). Some of the systems tested were conditionally recertified with new stringed security requirements imposed. The companies in question have until the February 2008 California Presidential Primaries to fix their security issues and insure that election results can be closely audited. The Premier Election Solutions (formerly Diebold Election Systems) AccuVote-TSx voting system was studied by a group of Princeton University computer scientists in 2006. Their results showed that the AccuVote-TSx was insecure and could be "installed with vote-stealing software in under a minute." The scientists also said that machines can transmit computer viruses from one to another "during normal pre- and post-election activity 2. India: - Omesh Saigal, an IIT alumnus and IAS officer blew the top of the Election Commissioner Navin Chawla in front of the whole nation when he successfully demonstrated that the 2009 elections in India when Congress Party of India came back to power might be rigged. This forced the election commission to review the current EVMs and brought bad reputation for Mr. Navin Chawla. - On October 30, 2006 the Dutch Minister of the Interior withdrew the license of 1187 voting machines from manufacturer Suds NV, about 10% of the total number to be used, because it was proven by the General Intelligence and Security Service that one could eavesdrop on voting from up to 40 meters using Van Eck phreaking. National elections are to be held 24 days after this decision. The decision was forced by the Dutch grass roots organization Wij vertrouwen stem computers net ("We do not trust voting computers"). 3. Finland: - In Finland, the Supreme Administrative Court declared invalid the results of a pilot electronic vote in three municipalities, and ordered a rerun of the municipal elections. The system had an usability problem where the messages were ambiguous on whether the vote had been cast. In a total of 232 cases (2% of votes), voters had logged in, selected their vote but not confirmed it, and left the booth; the votes were not recorded. Following the failure of the Page 16
  17. 17. pilot election, the Finnish government has abandoned plans to introduce electronic voting to the country. Page 17
  18. 18. Chapter Two System Analysis Page 18
  19. 19. 2.1 Methodologies Object Oriented Programming Object-oriented programming (OOP) is a programming paradigm that uses "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs. Programming techniques may include features such as data abstraction, encapsulation, modularity, polymorphism, and inheritance. It was not commonly used in mainstream software application development until the early 1990s. Many modern programming languages now support OOP. An object is a discrete bundle of functions and procedures, often relating to a particular real-world concept such as a voter or candidate. Other pieces of software can access the object only by calling its functions and procedures that have been allowed to be called by outsiders. A large number of software engineers agree that isolating objects in this way makes their software easier to manage and keep track of. However, a significant number of engineers feel the reverse may be true: that software becomes more complex to maintain and document, or even to engineer from the start. The conditions under which OOP prevails over alternative techniques (and vice-versa) often remain unstated by either party, however, making rational discussion of the topic difficult, and often leading to "religious wars" over the matter. Object-oriented programming has roots that can be traced to the 1960s. As hardware and software became increasingly complex, manageability often became a concern. Researchers studied ways to maintain software quality and developed object-oriented programming in part to address common problems by strongly emphasizing discrete, reusable units of programming logic. The technology focuses on data rather than processes, with programs composed of self-sufficient modules ("classes"), each instance of which ("objects") contains all the information needed to manipulate its own data structure ("members"). This is in contrast to the existing modular programming which had been dominant for many years that focused on the function of a module, rather than specifically the data, but equally provided for code reuse, and self-sufficient reusable units of programming logic, enabling collaboration Page 19
  20. 20. through the use of linked modules (subroutines). This more conventional approach, which still persists, tends to consider data and behavior separately. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent 'machine' with a distinct role or responsibility. The actions (or "methods") on these objects are closely associated with the object. For example, the data structures tend to 'carry their own operators around with them' (or at least "inherit" them from a similar object or class). In the conventional model, the data and operations on this data doesn't have a tight formal association. Fundamental concepts and features A survey by Deborah J. Armstrong of nearly 40 years of computing literature identified a number of "quarks", or fundamental concepts, found in the strong majority of definitions of OOP. Not all of these concepts are to be found in all object-oriented programming languages, and so object-oriented programming that uses classes is called sometimes class-based programming. In particular, prototype-based programming does not typically use classes. As a result, a significantly different yet analogous terminology is used to define the concepts of object and instance. Class 'A class defines' the abstract characteristics of a thing (object), including its characteristics (its attributes, fields or properties) and the thing's behaviors (the things it can do, or methods, operations or features). One might say that a class is a blueprint or factory that describes the nature of something. For example, the class Voter would consist of traits shared by all voters, such as Name and age color (characteristics), and the ability to cast vote (behaviors). Classes provide modularity and structure in an object-oriented computer program. A class should typically be recognizable to a non-programmer familiar with the problem domain, meaning that the characteristics of the class should make sense in context. Also, the code for a Page 20
  21. 21. class should be relatively self-contained (generally using encapsulation). Collectively, the properties and methods defined by a class are called members. Object An instance (that is, an actual example) of a class. Example 1: The class Voter is a pattern or blueprint for candidate objects by listing the characteristics and behaviors they can have; the object Ahmed is one particular candidate. Instance One can have an instance of a class; the instance is the actual object created at run-time. In programmer vernacular, the Ahmed object is an instance of the voter class. The set of values of the attributes of a particular object is called its state. The object consists of state and the behavior that's defined in the object's class. Method An object's abilities. In language, methods (sometimes referred to as "functions") are verbs. Ahmed, being a voter, has the ability to submit a vote So submit () is one of Ahmed's methods. He may have other methods as well, for example Login(). Within the program, using a method usually affects only one particular object; all voters can submit a vote, but you need only one voter to submit one vote. Message passing "The process by which an object sends data to another object or asks the other object to invoke a method."Also known to some programming languages as interfacing. For example, the object called AdminClerk may tell the Ahmed object to apply by passing a "submit" message which invokes Ahmed's "submit" method. The syntax varies between languages, for example: [Ahmed submit] in Objective-C. In Java, code-level message passing corresponds to "method calling". Some dynamic languages use double-dispatch or multi-dispatch to find and pass messages. Inheritance "Subclasses" are more specialized versions of a class, which inherit attributes and behaviors from their parent classes, and can introduce their own. For example, the class person might have sub-class called Page 21
  22. 22. voter. In this case, Ahmed would be an instance of the voter subclass. Suppose the people class defines a method called View() and a property called name. Each of its sub-classes (voter, candidate, and judge) will inherit these members, meaning that the programmer only needs to write the code for them once. Each subclass can alter its inherited traits. For example, the voter subclass might specify that the default status for a voter is true. The Subclasses can also add new members. The voter subclass could add a method called submit(). So an individual Ahmed instance would use a high-pitched submit() from the voter subclass. The Baradey object would also have the apply() method, but Ahmed would not, because he is a candidate, not a voter. In fact, inheritance is an "a... is a" relationship between classes, while instantiation is an "is a" relationship between an object and a class: a voter is a person ("a... is a"), but ahmed is a voter ("is a"). Thus, the object named Ahmed has the methods from both classes voter and person. Multiple inheritances is inheritance from more than one ancestor class, neither of these ancestors being an ancestor of the other. For example, independent classes could define person and community, and a Ahmed object could be created from these two which inherits all the (multiple) behavior of person and community. This is not always supported, as it can be hard to implement. Abstraction Abstraction is simplifying complex reality by modeling classes appropriate to the problem, and working at the most appropriate level of inheritance for a given aspect of the problem. For example, Ahmed the Voter may be treated as a voter much of the time, a community instance when necessary to access community-specific attributes or behaviors, and as a person (perhaps the parent class of voter). Encapsulation Encapsulation conceals the functional details of a class from objects that send messages to it. For example, the voter class has a submit() method. The code Page 22
  23. 23. for the submit() method defines exactly how a submition happens (e.g., by login() and then verify(), at a particular pitch and volume). Ali, Ahmed's friend, however, does not need to know exactly how he votes. Encapsulation is achieved by specifying which classes may use the members of an object. The result is that each object exposes to any class a certain interface — those members accessible to that class. The reason for encapsulation is to prevent clients of an interface from depending on those parts of the implementation that are likely to change in the future, thereby allowing those changes to be made more easily, that is, without changes to clients. Members are often specified as public, protected or private, determining whether they are available to all classes, sub- classes or only the defining class. Some languages go further: Java uses the default access modifier to restrict access also to classes in the same package, C# and VB.NET reserve some members to classes in the same assembly using keywords internal (C#) or Friend (VB.NET), and Eiffel and C++ allow one to specify which classes may access any member. Polymorphism(Subtype) Polymorphism allows the programmer to treat derived class members just like their parent class's members. More precisely, Polymorphism in object-oriented programming is the ability of objects belonging to different data types to respond to calls of methods of the same name, each one according to an appropriate type-specific behavior. One method, or an operator such as +, -, or *, can be abstractly applied in many different situations. Decoupling Decoupling allows for the separation of object interactions from classes and inheritance into distinct layers of abstraction. A common use of decoupling is to polymorphically decouple the encapsulation, which is the practice of using reusable code to prevent discrete code modules from interacting with each other. However, in practice decoupling often involves trade- offs with regard to which patterns of change to favor. The science of measuring these trade-offs in respect to actual change in an objective way is still in its infancy. Page 23
  24. 24. Design Patterns In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Design patterns reside in the domain of modules and interconnections. At a higher level there are Architectural patterns that are larger in scope, usually describing an overall pattern followed by an entire system. Not all software patterns are design patterns. For instance, algorithms solve computational problems rather than software design problems. Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns. In order to achieve flexibility, design patterns usually introduce additional levels of indirection, which in some cases may complicate the resulting designs and hurt application performance. By definition, a pattern must be programmed anew into each application that uses it. Since some authors see this as a step backward from software reuse as provided by components, researchers have worked to turn patterns into components. Meyer and Arnout claim a two-thirds success rate in componentizing the best-known patterns. Often, people only understand how to apply certain software design techniques to certain problems. These techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that doesn't require specifics tied to a particular problem. ECC Pattern Engine-Collection-Class, a Design Pattern for Building Reusable Enterprise Components The Enterprise Computing Center Page 24
  25. 25. (ECC) is a research center of the ETH Zürich established in collaboration with industry to promote education, research, and technology transfer in the general areas of enterprise IT architecture, enterprise computing, enterprise application integration, middleware, high performance and large scale data management, multi-tier architectures, and service oriented architectures. The charter of the ECC involves: • To conduct advanced research as part of joint projects with the industrial partners. • To pursue graduate education programs (Master / Ph.D. level) that better prepare students for the problems they will encounter in industry. • To establish a permanent dialogue between academic research and industry on technology, education, and research, acting as a vehicle and catalyst for information exchanges across companies and the development of a better understanding of the problems surrounding enterprise computing. Adaptor pattern In computer programming, the adapter design pattern (often referred to as the wrapper pattern or simply a wrapper) translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms. For instance, if multiple Boolean values are stored as a single integer but your consumer requires a 'true'/'false', the adapter would be responsible for extracting the appropriate values from the integer value. Three-tier architecture is a client–server architecture in which the user interface, functional process logic ("business rules"), computer data storage and data access are developed and maintained as independent modules, most often on separate platforms. It was developed by John J. Donovan in Open Environment Page 25
  26. 26. Corporation (OEC), a tools company he founded in Cambridge, MA. The three-tier model is a software architecture and a software design pattern. Apart from the usual advantages of modular software with well-defined interfaces, the three-tier architecture is intended to allow any of the three tiers to be upgraded or replaced independently as requirements or technology change. For example, a change of operating system in the presentation tier would only affect the user interface code. Typically, the user interface runs on a desktop PC or workstation and uses a standard graphical user interface, functional process logic may consist of one or more separate modules running on a workstation or application server, and an RDBMS on a database server or mainframe contains the computer data storage logic. The middle tier may be multi- tiered itself (in which case the overall architecture is called an "n-tier architecture"). Three-tier architecture has the following three tiers: Presentation tier This is the topmost level of the application. The presentation tier displays information related to such services as browsing merchandise, purchasing, and shopping cart contents. It communicates with other tiers by outputting results to the browser/client tier and all other tiers in the network. Application tier (business logic, logic tier, data access tier, or middle tier) The logic tier is pulled out from the presentation tier and, as its own layer, it controls an application’s functionality by performing detailed processing. Data tier This tier consists of database servers. Here information is stored and retrieved. This tier keeps data neutral and independent from application servers or business logic. Giving data its own tier also improves scalability and performance. Page 26
  27. 27. 3 tier Architecture 1 Web Application In system software, a web application is an application that is accessed over a network such as the Internet or an intranet. The term may also mean a computer software application that is hosted in a browser-controlled environment (e.g. a Java applet)[citation needed] or coded in a browser-supported language (such as JavaScript, combined with a browser- rendered markup language like HTML) and reliant on a common web browser to render the application executable. Web applications are popular due to the ubiquity of web browsers, and the convenience of using a web browser as a client, sometimes called a thin client. The ability to update and maintain web applications without distributing and installing software on potentially thousands of client computers is a key reason for their popularity, as is the inherent support for cross- platform compatibility. Common web applications include webmail, online retail sales, online auctions, wikis and many other functions. The web interface places very few limits on client functionality. Through Java, JavaScript, DHTML, Flash and other technologies, application-specific methods such as drawing on the screen, playing audio, and access to the keyboard and mouse are all possible. Many services have worked to combine all of these Page 27
  28. 28. into a more familiar interface that adopts the appearance of an operating system. General purpose techniques such as drag and drop are also supported by these technologies. Web developers often use client-side scripting to add functionality, especially to create an interactive experience that does not require page reloading. Recently, technologies have been developed to coordinate client-side scripting with server-side technologies such as PHP. Ajax, a web development technique using a combination of various technologies, is an example of technology which creates a more interactive experience. Applications are usually broken into logical chunks called "tiers", where every tier is assigned a role. Traditional applications consist only of 1 tier, which resides on the client machine, but web applications lend themselves to a n-tiered approach by nature. Though many variations are possible, the most common structure is the three-tiered application Distributed Data Base We can define a distributed database (DDB) as a collection of multiple logically interrelated databases distributed over a computer network, and a distributed database management system (DDBMS) as a software system that manages a distributed database while making the distribution transparent to the use. A collection of files stored at different nodes of a network and the maintaining of interrelationships among them via hyperlinks has become a common organization on the Internet, with files of Web pages. Reasons of DDB 1. More computer power is harnessed to solve a complex task, and. 2. Each autonomous processing element can be managed independently and develop its own applications. Page 28
  29. 29. Some different database system architectures. (a) Shared nothing architecture. (b) A networked architecture with a centralized database at one of the sites. (c) A truly distributed database architecture. Shared nothing architecture. 1 A networked architecture with a centrali 1 Page 29
  30. 30. Truly distributed database architecture 1 Advantages of DDB: - Increased reliability and availability: These are two of the most common potential advantages cited for distributed databases. Reliability is broadly defined as the probability that a system is running (not down) at a certain time point, whereas availability is the probability that the system is continuously available during a time interval. When the data and DBMS software are distributed over several sites, one site may fail while other sites continue to operate. Only the data and software that exist at the failed site cannot be accessed. This improves both reliability and availability. Further Page 30
  31. 31. improvement is achieved by judiciously replicating data and software at more than one site. In a centralized system, failure at a single site makes the whole system unavailable to all users. In a distributed database, some of the data may be unreachable, but users may still be able to access other parts of the database. - Improved performance: A distributed DBMS fragments the database by keeping the data closer to where it is needed most. Data localization reduces the contention for CPU and I/O services and simultaneously reduces access delays involved in wide area networks. When a large database is distributed over multiple sites, smaller databases exist at each site. As a result, local queries and transactions accessing data at a single site have better performance because of the smaller local databases. In addition, each site has a smaller number of transactions executing than if all transactions are submitted to a single centralized database. Moreover, inter query and inter query parallelism can be achieved by executing multiple queries at different sites, or by breaking up a query into a number The potential advantages Of DDBMS The DDBMS software must be able to provide the following functions in addition to those of a centralized DBMS: - Keeping track of data: The ability to keep track of the data distribution, fragmentation, and replication by expanding the DDBMS catalog. - Distributed query processing: The ability to access remote sites and transmit queries and data among the various sites via a communication network. - Distributed transaction management: The ability to devise execution strategies for queries and transactions that access data from more than one site and to synchronize the access to distributed data and maintain integrity of the overall database. - Replicated data management: The ability to decide which copy of a replicated data item to access and to maintain the consistency of copies of a replicated data item. - Distributed database recovery: The ability to recover from individual site crashes and from new types of failures such as the failure of a communication links. Page 31
  32. 32. - Security: Distributed transactions must be executed with the proper management of the security of the data and the authorization/access privileges of users. - Distributed directory (catalog) management: A directory contains information (metadata) about data in the database. The directory may be global for the entire DDB, or local for each site. The placement and distribution of the directory are design and policy issues. 2.2 Feasibility Analysis:- SWOT/PEST Analysis In this section, not only the SWOT but also the PEST factors are examined to assess the current and prospective states of e-voting in Egypt by using a practical approach. SWOT analysis is employed to discuss strengths (S), weaknesses (W), opportunities (O) and threats (T) of e-Voting in Egypt. Each of the four components of SWOT analysis is further examined according to PEST factors, referring to political (P), economic (E), social (S) and technological (T) determinants. Strengths The strengths of Egypt to develop and maintain e-Voting lie with the public policy. This is an important political determinant in the PEST model. Political: After 25 January revolution, the need for a system that automate the election process, to facilitate the participation of the large amount of voters into the process of the election, and help in getting rid of all means of fraud. Economic: Implementing E-Voting system with central database will decrease transposition cost for voting boxes, as this costs will be replaced by the cost of intranet used for voting system. Implementing such a system will guide business to such a field of providing services to the government and automating their process, this will open new job vacancies for IT people. Social: Page 32
  33. 33. Implementing such a system in Egypt will gain the attention of people to IT, and hence this system can help in removing technology Illiteracy. Automating the system will decrease the time of voter verification and hence will decrease the time of the voting process and voting queues, helping in preventing valance among voters. The idea of automating voting process will gain voter respects and trust, since no one has control on their decisions. Technology strengths: The system will utilize the technology and make benefits of it. New infrastructure will be added, and the system will reflect the effect of technology on the public live and will encourage innovation. Opportunities Political: In spite of the abovementioned shortcomings, there are many opportunities for E-Voting to grow in Egypt. The political willingness of leaders to build and automate the voting process creates an opportunity for businesses in Egypt to show their commitment to E- Voting, and government may help in planning, designing and implementing such a system. Economic: People with IT proficiency have better opportunities for employment since computer literacy is a requirement for most industries in Egypt. Thus, people are motivated to learn computer skills. Time constraints are another motive to urge the public to adopt e-Services. Social: The system provide opportunities for the society as it direct their attention to the technology and how it can they help them in their live to improve, provide opportunities for voters to get rid from their fairs of frauds by all its means or affecting their opinions. Technology: The development of new technology applications presents opportunities for better, cheaper and more efficient e-services. Page 33
  34. 34. Weaknesses Political: Traditionally, the public believe that the old government always wants to introduce new methods and new approaches to return to political live. This belief may cause people to hesitate in trying E- Voting. Other weaknesses are the public feelings of insecurity and concern about making mistakes and being fined. These issues discourage people from tapping into E-Voting. Economic: Economic costs for providing all infrastructures required to run the system and so the original version of software applications used. Social: Large portion of blue-collar workers and the older generation is still computer illiterate. Others may find it difficult to follow instructions on the Internet or may be discouraged by computer-related problems. Technology: Less IT-savvy people and the older generation are afraid of computer related problems. The performance and traffic on the server is another issue. Threats Political: Opposition system may take advantage of the Internet to spread propaganda on their ideologies and to create social disorder as they can question about the electronic system depending on most people illiteracy with the IT. Security breaches are another problem for E-Voting. The loopholes in the legal system and advanced technology make it easy for hackers to penetrate portal and steal confidential information. This will create insecurity among voters who then may not be so willing to trust service. Internet and computer related crimes, such as hacking, scam, spam, phishing or identity fraud and theft, will hinder the development of E-Voting. If problems relating to security and privacy are not properly addressed, voter could hesitate to use the service. Economic: Page 34
  35. 35. Economic threat for increasing of technologies costs. Social: Rapid development of telecommunication and competition is major threats. Mobile voting may be developed that lead the user to avoid using our system. Competition may lead another company to develop a system with easier technologies and infra structure. Technology: The dependence of people on technology may produce the adverse effect of people serving technology, instead of technology serving people. An electronic crisis may disrupt activities and the whole country could be paralyzed without any Internet connection. Computer viruses, worms and computer bugs may affect the result counting function. Network problems are also a major barrier. Users may feel helpless when they have to deal with technological problems. Page 35
  36. 36. SWOT/PEST Analysis Summery SWOT/ Strength Weaknesses Opportunities Threats PEST (S) (W) (O) (T) - Cyber terrorism - Public policy Conservation in and cyber Political Political trying e- crimes aspect (P) willingness Services - Security breach - Economic policies - Funds for eservices IT-proficient To improve Infrastructure people can have Infrastructure Economic social and costs better costs aspect (E) physical Software costs opportunity for Software costs infrastructure employment - Low cost of Internet subscripti on - Remove technology Workers and The rapid - IT Illiteracy older development of Social aspect Education - Decrease generation mobile (S) are computer - Fraud technology violence illiterate prevention competition Gain voter trust - Some government Dependency on - High-tech websites are IT, i.e. small Technological based unfriendly-user Broadband technical aspect Economy - Over- facilitates faster problems will (T) - Innovatio capacity connection disrupt the n of the Internet entire networks highway due to heavy traffic Page 36
  37. 37. 2.3 Major Identified Risks Threat Consequence Likelihood Counter measures Trojan horse No known example, installed by Wholesale but theoretically Operating possible System vendor Prevents Develop Lack of adequate testing Certain standards (a standards of Voting system slow process) Configuration Stronger legal Lack of change could Known problems with sanctions – but configuration introduce new configuration oversight is oversight voting oversight expensive compromises Potential for Better testing multiple voting, and Buggy software Unknown loss of voter certification of privacy voting systems Common, occurred No simple Denial of Disenfranchisem during Canadian counter Service ent Internet election measures Detection difficult. Individual PCs Trojan horse can be spyware to Vote theft, loss of Widely available tools protected, but change or privacy for this assuring monitor votes compliance difficult, especially for public PCs. Page 37
  38. 38. 2.4 Requirement specification:- Functional Requirements: The main features in the system are: A- Pre-voting phase: 1- Manage admin 2- Manage election committee 3- Manage candidates 4- Manage voters B- Voting phase 1- Submit vote C- Post-voting phase 1- View results 2- Generate reports Module 1: Manage Admin Module 1- Super admin must be able to add new admin with specific privileges to the system. 2- Super admin must be able to edit admin. 3- Super admin shall be able to delete admin. 4- Super admin shall be able to view admin information and privileges. Page 38
  39. 39. 5- Super admin may be able to sort admins by committee, privileges, and names. 6- Super admin may be able to filter admins by committee, privileges. 7- Super admin may be able to search for a specific admin Module 2: Manage election committee Module 1- Admin must be able to add new committee election. 2- Admin must be able to edit exiting committee election. 3- Admin shall be able to delete existing committee election. 4- Admin shall be able to view committee information. 5- Admin may be able to sort committee by name, location. 6- Admin may be able to filter committee by locations. 7- Admin may be able to search for a specific committee. Module 3: Manage candidate 1- Admin must be able to add new candidate. 2- Admin must be able to edit exiting candidate. 3- Admin shall be able to delete existing candidate. 4- Admin shall be able to view candidate. 5- Admin may be able to sort candidate by name, location. 6- Admin may be able to filter candidate by committee. 7- Admin may be able to search for a specific candidate. Module 4: Manage Voters 1- Admin must be able to add new Voter. 2- Admin must be able to edit exiting voter. 3- Admin shall be able to delete existing voter. 4- Admin shall be able to view voter. 5- Admin may be able to sort voter by name, location. 6- Admin may be able to filter voter by committee assigned to. 7- Admin may be able to search for a specific voter. Module 5: Voting Voters module 1- Voter must be able to login to the system. 2- User must be able to submit vote. 3- Admin must be able to verify user SSN. Module 6: Result management module 1- Judge/auditor must be able to filter result according to votes per committee, votes per candidates, and votes per candidate and committee. B) Non-Functional Requirements: Security Requirements - The security requirements for this system span all aspects of the voting process and include voter authenticity, voter Page 39
  40. 40. anonymity, data confidentiality, data integrity, system accountability, system integrity, system availability, system assurance, and system reliability - An individual not registered to vote must not be able to cast a ballot - A voter must not be able to vote more than once - The privacy of the vote has to be guaranteed during the casting, transfer, reception, collection, and tabulation of votes - No voter should be able to prove that they voted in a certain way - None of the participants involved in the voting process (organizers, election officials, trusted third parties, voters, etc) should be able to link a vote to an identifiable voter - Each vote is recorded precisely as the voter intended - Each voter is ensured a "clean slate" of the system to ensure equality, confidence, and minimize system tampering - The outcome of the voting process must correspond to the votes cast - It should be infeasible to exclude a valid vote from the tabulation, and to validate a non-valid one - System and voter operations are logged and audited - The system cannot be re-configured during operation - Access to voted ballots is prohibited until after the close of the polls - Additional ballots cannot be cast once the polling place has closed - The system must be open to independent inspection and auditing - The system is protected against accidental and malicious denial of service attacks Privacy: the voting system has to protect privacy, concealing the relation between voter and his/her cast vote, and ensuring that the voter's choice will remain anonymous. This requirement must be fulfilled once the voter has cast his/her vote and must be preserved during the counting processes. Integrity: A voting system has to protect the vote against manipulation once it is cast and until it is counted. Therefore the channel must to provide measures to prevent and/or detect any attempted to change the voter's intent once the vote has been cast. Page 40
  41. 41. Voter Verifiability – Cast as Intended: Voter must have the possibility to check that his/her vote has been accurately recorded. In the case of remote voting, this implies the availability to check if the vote received by the election officials and stored in the remote Ballot Box (in a physical or electronic manner) is the same as cast by the voter. It is important to note that the requirement cannot conflict with others once. Voter Verifiability – Counted as Cast: In the counted as cast verification, voters must have the possibility to verify the inclusion of his/her vote in the final tally. It is considered as security improvement. Prevention of Intermediate results: It is important to prevent the disclosure of intermediate results before the election is closed. This way, or the voters have the same information during the voting stage. This implies that the secrecy of the vote must be preserved until the tally process. Ballot Box Accuracy: Protection of the ballot box against the addition of bogus ballots or the elimination of valid ballots is needed. In the case that multiple voting is allowed, this measured must guarantee that one vote per voter will be counted. Prevention of Voting Errors: The voting channel has to prevent involuntary voting errors by voters when casting their votes (e.g., under-voting, over-voting). This practice is becoming more common for poll-site voting in complex elections. Ease of Use: the voting channel must be easy to use by average voters. In remote voting this requirement is of paramount importance to prevent disenfranchisement and facilitate the participation of voters. Correctness: All input votes are correctly counted and no other votes are counted Robustness: The counting tolerates the corrupt or faulty behavior of any group of authorities up to a threshold. Page 41
  42. 42. 2.5 Domain Model Page 42
  43. 43. 2.6 Use Cases Manage Judge/Admin-clerk Page 43
  44. 44. Administrator add new judge / admin-clerk Description Administrator must be able to add judge / admin-clerk. Administrator add judge / admin-clerk Title: Administrator adds judge/admin-clerk personal. Intent: Describe Administrator interacts with the system during add data about new judge/admin-clerk as an initial data. Preconditions Administrator login to the system Actors • Administrator Main Scenario 1- Administrator enters data about new judge/admin- clerk (User id – user name – SSN – title – address - mission). Specification 2- Administrator press save button s 3- Data is saved and confirmation message appear that data is saved successfully. Alternate Scenario1 1- Wrong User id entered (duplicate User id) 2- System displays a message that (invalid User id, User id already exist) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 44
  45. 45. Administrator edit judge / admin- clerk Description Administrator must be able to edit judge / admin-clerk. Administrator edits judge / admin-clerk Title: Administrator edits judge/admin-clerk personal data. Intent: Describe Administrator interacts with the system during editing judge/admin-clerk personal data. Preconditions Administrator login to the system. Judge/admin-clerk data already recorded. Actors 1- Administrator Main Scenario 1- Administrator selects judge/admin-clerk user id for the record to be displayed. 2- Administrator amends data. 3- Administrator press save button 4- Confirmation message appear that data is saved Specification successfully. s Alternate Scenario1 1- Wrong user id entered. 2- System displays a message that (invalid user id, user id does not exist) Alternate Scenario2 (Voting Day) 1- The system does not permit editing during voting Process. 2- System displays a message that (Voting is in process) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 45
  46. 46. Administrator deletes judge / admin- clerk Description Administrator must be able to delete judge / admin-clerk Administrator deletes judge / admin-clerk Title: Administrator deletes judge / admin-clerk ion. Intent: Administrator interacts with the system during deleting judge / admin-clerk. Preconditions Administrator login. judge / admin-clerk data already recorded. Actors 1- Administrator Main Scenario 1- Administrator selects judge / admin-clerk to be displayed and press delete. 2- Confirmation message displayed to confirm deletion Specification process. s 3- Administrator press delete button. 4- Precinct and Poll Station is deleted. Alternate Scenario1 (Voting Day) 1- The system does not permit deleting during voting Process. 2- System displays a message that (Voting is in process) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Administrator displays judge / admin-clerk Description Administrator must be able to display judge / admin- Page 46
  47. 47. clerk. Administrator displays judge / admin-clerk Title: Administrator displays judge / admin-clerk data. Intent: Describe Administrator interacts with the system during displaying judge / admin-clerk tion data. Preconditions Administrator login. Judge / admin-clerk data already recorded. Actors: Administrator Main Scenario 1- Administrator login to Manage judge / admin-clerk module. All judge / admin-clerk appear with their basic data (User id – user name – SSN – title – address - mission). 2- Administrator selects a judge / admin-clerk. 3- judge / admin-clerk information is displayed in details. Alternate Scenario1 1- The first time Administrator is logged to the system and no judge / admin-clerk exists Specification 2- The system displays a message welcome the Administrator and tells him that there is no data is recorded in the system s yet. Uses/Extends Included1 Sort: 1- Administrator presses any column title in the display page (User id – user name – SSN – title – address - mission). 2- Precinct and Poll Station are sorted according to the pressed column title. Included2 Search: 1- Administrator type judge / admin-clerk name and press search button 2- Matching judge / admin-clerk appear in the result. 3- If there is no result, not found message appear. Included3 Filter: 1- Administrator selects criteria to filter with (title, mission) 2- Matching candidates appear in the result. 3- If there is no result, not found message appear. Frequency Frequent Issues N/A Priority High Page 47
  48. 48. Manage Precinct & Poll Station Page 48
  49. 49. Add new Precinct and Poll Station Administrator must be able to add new Precinct or Poll Description Station. Administrator adds precinct and poll station Title: Administrator adds new Precinct or Poll Station. Intent: Describe Administrator interacts with the system during add data about new Precinct or Poll Station as an initial data. Preconditions Administrator login to the system Actors • Administrator Main Scenario 4- Administrator enters data about new Precinct or Poll Station (Code – name – governorate - district - address – Judge ID) Specifications 5- Administrator press save button 6- Data is saved and confirmation message appear that data is saved successfully. Alternate Scenario1 3- Wrong code entered (duplicate code) 4- System displays a message that (invalid code, code already exist) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 49
  50. 50. Edit Precinct and Poll Station data Administrator must be able to edit Precinct and Poll Description Station. Administrator edits Voter Title: Administrator edits Precinct and Poll Station data. Intent: Describe Administrator interacts with the system during editing Precinct and Poll Station data. Preconditions Administrator login to the system. Precinct and Poll Station data already recorded. Actors 2- Administrator Main Scenario 5- Administrator selects Precinct and Poll Station id for the record to be displayed. 6- Administrator amends data. 7- Administrator press save button 8- Confirmation message appear that data is saved Specification successfully. s Alternate Scenario1 3- Wrong code entered. 4- System displays a message that (invalid id, id does not exist) Alternate Scenario2 (Voting Day) 3- The system does not permit editing during voting Process. 4- System displays a message that (Voting is in process) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 50
  51. 51. Delete Precinct and Poll Station data Administrator must be able to delete Precinct and Poll Description Station Administrator deletes Precinct and Poll Station Title: Administrator deletes Precinct and Poll Station. Intent: Administrator interacts with the system during deleting Precinct and Poll Station. Preconditions Administrator login. Precinct and Poll Station data already recorded. Actors 2- Administrator Main Scenario 5- Administrator selects Precinct and Poll Station to be displayed and press delete. 6- Confirmation message displayed to confirm deletion Specifications process. 7- Administrator press delete button. 8- Precinct and Poll Station is deleted. Alternate Scenario1 (Voting Day) 3- The system does not permit deleting during voting Process. 4- System displays a message that (Voting is in process) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 51
  52. 52. Display Precinct and Poll Station Data Administrator must be able to display Precinct and Poll Description Station. Administrator displays Precinct and Poll Station Title: Administrator displays Precinct and Poll Station data. Intent: Describe Administrator interacts with the system during displaying Precinct and Poll Station data. Preconditions Administrator login. Precinct and poll data already recorded. Actors 1- Administrator Main Scenario 4- Administrator login to Manage Precinct and Poll Station module. All Precinct and Poll Station appear with their basic data (Code – name – governorate - district - address – Judge ID) 5- Administrator selects a Precinct and Poll Station. 6- Precinct and Poll Station information is displayed in details. Alternate Scenario1 Specification 3- The first time Administrator is logged to the system and s no Precinct and Poll Station exists 4- The system displays a message welcome the Administrator and tells him that there is no data is recorded in the system yet. Uses/Extends Included1 Sort: 3- Administrator press any column title in the display page (code, Name, governorate, district- address- judge id) 4- Precinct and Poll Station are sorted according to the pressed column title. Included2 Search: 4- Administrator type Precinct and Poll Station name and press search button 5- Matching Precinct and Poll Station appear in the result. 6- If there is no result, not found message appear. Included3 Filter: 4- Administrator selects criteria to filter with (governorate, judge) 5- Matching candidates appear in the result. 6- If there is no result, not found message appear. Frequency Frequent Issues N/A Priority High Page 52
  53. 53. Manage Candidate Page 53
  54. 54. Add new Candidate Description Administrator must be able to add new candidate. Administrator adds candidate Title: Administrator adds Voter data. Intent: Describe Administrator interacts with the system during add data about candidate as an initial data. Preconditions Administrator login to the system Actors • Administrator Main Scenario 7- Administrator enters data about Candidate (SSN - name - Birth date –Age – Governorate - District – Address, image, election symbol). Specification 8- Administrator press save button s 9- Data is saved and confirmation message appear that data is saved successfully. Alternate Scenario1 5- Wrong SSN entered (duplicate id) 6- System displays a message that (invalid id, id already exist) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 54
  55. 55. Edit Voter date Description Administrator must be able to edit Voter. Administrator edits Voter Title: Administrator edits candidate data. Intent: Describe Administrator interacts with the system during editing candidate data. Preconditions Administrator login to the system. Candidate data already recorded. Actors 3- Administrator Main Scenario 9- Administrator enters candidate id for the record to be displayed. 10-Administrator amends data. 11-Administrator press save button 12-Confirmation message appear that data is saved Specification successfully. s Alternate Scenario1 5- Wrong id entered. 6- System displays a message that (invalid id, id does not exist) Alternate Scenario2 (Voting Day) 5- The system does not permit editing during voting Process. 6- System displays a message that (Voting is in process) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 55
  56. 56. Delete Candidate data Description Administrator must be able to delete candidate. Administrator deletes candidate Title: Administrator deletes candidate. Intent: Administrator interacts with the system during deleting canidate. Preconditions Administrator login. candidate data already recorded. Actors 3- Administrator Main Scenario 9- Administrator selects candidate to be displayed and press delete. 10- Confirmation message displayed to confirm deletion Specification process. s 11- Administrator press delete button. 12-Candidate is deleted. Alternate Scenario1 (Voting Day) 5- The system does not permit deleting during voting Process. 6- System displays a message that (Voting is in process) Uses/Extends N/A Frequency Frequent Issues N/A Priority High Page 56

×