sSoftware Requirements Specification (SRS) for Online Voting Management

System

1. Introduction

1.1 Purpose

The purpose of this document is to define the requirements for an Online Voting
Management System (OVMS). This system allows eligible users to register, manage
candidates and voter information, securely cast votes, receive notifications, and generate real-
time results, ensuring an efficient and secure voting experience.

1.2 Scope

The OVMS will be a web-based application supporting multiple user roles, including voters,
administrators, and election officials. Core functionalities include user registration, candidate
management, voting, result processing, and notifications.

1.3 Definitions, Acronyms, and Abbreviations

 OVMS: Online Voting Management System

 Admin: Administrator responsible for managing users and elections
 Voter: Registered user eligible to vote in an election
 Election Official: Oversees the election process and monitors voting activities

2. Overall Description

2.1 Product Perspective

OVMS is a self-contained, secure online system that interacts with a centralized database for
storing data and integrates with external APIs for security features, like two-factor
authentication.

2.2 Product Functions

 User Registration and Management

 Voting Process and Verification
 Result Processing and Display
 Candidate Management
 Notifications and Alerts
 Administrative Reporting and Monitoring

2.3 User Classes and Characteristics

1. Voter: Registers to vote and is eligible to vote in elections.

2. Admin: Manages elections, candidates, and users.

1
 3. Election Official: Monitors the voting process and manages voter eligibility and
security.

2.4 Operating Environment

The system will be a web-based application accessible on desktop and mobile browsers,
compatible with major browsers (Chrome, Firefox, Safari, Edge).

2.5 Assumptions and Dependencies

 Users require stable internet connectivity.

 A secure server for data encryption and user authentication.
 Compliance with local data privacy and voting regulations.

3. Functional Requirements

3.1 Registration Module

 Allows users to register with personal details and verify their eligibility.
 Assigns roles (Voter, Candidate, Admin) upon successful registration.
 Supports password and two-factor authentication for security.

3.2 Voting Module

 Provides each verified voter with a unique, anonymous ballot.

 Ensures each eligible voter can vote only once per election.
 Encrypts votes for secure, anonymous storage.

3.3 Result Processing Module

 Calculates and displays real-time results based on votes cast.

 Aggregates vote data and provides a summary for publication.
 Exports results in formats suitable for analysis.

3.4 Notification Module

 Sends registration confirmations, election updates, and reminders to users.

 Notifies users of important changes, results, and system alerts via email/SMS.

3.5 Candidate Management Module

 Allows admins to add, edit, and remove candidate profiles.

 Displays candidate information for voters’ reference.
 Updates candidate statuses as necessary.

3.6 User Management Module

 Manages user accounts, including activation, deactivation, and role changes.

 Monitors user activity logs for auditing and security.

2
3.7 Authentication and Authorization Module

 Manages user login with secure credentials and two-factor authentication.

 Defines access control for various roles (Admin, Voter, Election Official).

4. Non-Functional Requirements

4.1 Security Requirements

The system will employ SSL encryption, store user passwords securely, and implement
automatic logout after inactivity.

4.2 Usability Requirements

An intuitive, user-friendly interface with accessible navigation will be provided, adhering to

WCAG 2.1 standards to support visually impaired users.

4.3 Performance Requirements

The system will support up to 10,000 concurrent users, maintaining an average page load
time of 3 seconds.

4.4 Reliability Requirements

The system will maintain a 99.9% uptime during election periods, with data backed up every
15 minutes while voting is active.

5. External Interface Requirements

5.1 User Interface

A responsive UI with dashboards specific to each role (Voter, Admin, Election Official) will
be designed to ensure clarity and usability.

5.2 Hardware and Software Interfaces

The system will operate on standard desktop and mobile devices, accessible through web
browsers on all common operating systems.

5.3 Communication Interfaces

The system will utilize HTTPS protocol and employ web sockets to provide real-time status
updates during the voting process.

6. System Features

3
  Voter Registration and Verification: Handles new user registration, eligibility
verification, and assignment of user roles.
 Voting System with Ballot Submission: Facilitates secure, anonymous voting and
prevents multiple votes from a single user.
 Real-Time Results Display: Displays voting results in real time and final summaries
after voting closes.
 Notifications and Alerts: Provides notifications related to elections, results, and
account status changes.
 Administrative Dashboard and Monitoring: Allows admins to monitor system
logs, track voter activity, and ensure system security.

7. Other Requirements

7.1 Legal Requirements

The system will comply with local and international laws concerning data privacy and online
voting regulations.

7.2 Ethical Requirements

The system will store votes anonymously to respect voter confidentiality, with no tracking of
individual voting choices.

4
1. ER Diagram

The Entity-Relationship Diagram (ER Diagram) serves as the foundational blueprint for
the system's database design. It captures the relationships between various entities involved in
the Online Voting Management System (OVMS), ensuring logical and organized data
storage. Key elements include:

 Entities: These represent real-world objects, such as User, Candidate, Election, and
Vote.
 Attributes: For example, the User entity might have attributes like userID, name,
email, and role, while Vote might include voteID and timestamp.
 Relationships: The diagram illustrates how entities are interconnected, such as a
User casting a Vote in an Election.
 Cardinality: Defines the relationship's nature, such as one-to-many between Election
and Candidate.
This diagram helps establish a well-structured, normalized database for the OVMS.

5
2. Activity Diagram

The Activity Diagram illustrates the sequence of actions and decisions that take place within
the system, providing a comprehensive overview of the system's workflow. Key features
include:

 Start and End Points: The diagram begins with user registration and concludes with
result generation.
 Action States: Depict specific processes like User Registration, Eligibility
Verification, and Vote Submission.
 Decision Nodes: Represent points where conditions must be evaluated, such as Is the
user eligible to vote?
 Swimlanes: Divide the diagram into roles (e.g., Voter, Admin, System) to show the
responsibilities of each actor.
The activity diagram ensures clarity in understanding the system's functional flow,
especially the voting and result-processing lifecycle.

6
3. Use Case Diagram

The Use Case Diagram provides a high-level visual representation of the interactions
between users (actors) and the system's functionalities. It includes:

 Actors: These are the system's users, such as Voters, Admins, and Election Officials.
 Use Cases: Define the system's functionalities, such as Register, Login, Cast Vote, Manage
Candidates, and View Results.
 Relationships:
o Associations: Show direct interactions (e.g., Voters are associated with Register and
Vote).
o Generalization: Depicts role hierarchies (e.g., Admins and Election Officials as
subtypes of User).
This diagram clarifies the system's capabilities and the roles' responsibilities in
achieving those functionalities.

7
4. Class Diagram

The Class Diagram details the static structure of the system, focusing on its objects, their
attributes, and their relationships. Key components include:

 Classes: Represented as boxes, e.g., User, Election, Vote, and Notification.

 Attributes: Characteristics of classes, such as name and role for User or electionDate for
Election.
 Methods: Actions performed by or on classes, such as registerUser(),
addCandidate(), or generateResults().
 Relationships:
o Associations: Show interactions between classes (e.g., User casts a Vote).
o Inheritance: Depicts hierarchical relationships (e.g., Admin inherits from User).
o Multiplicity: Indicates cardinality, such as one Election having multiple Votes.
This diagram helps developers understand the data structure and codebase design.

8
5. Sequence Diagram

The Sequence Diagram focuses on the dynamic aspects of the system by showing how
objects interact during specific processes. It includes:

 Objects: Represent system components such as User Interface, Authentication Module,

Voting Module, and Database.
 Lifelines: Indicate the lifespan of objects during the interaction process.
 Messages: Depict communications between objects, such as validateUser(), storeVote(), and
fetchResults().
 Activation Bars: Highlight when an object is actively processing a message.
The sequence diagram provides a step-by-step visualization of interactions, ensuring smooth
execution of processes like registration, voting, and result display.

9
Data Flow Diagram (DFD)

The Data Flow Diagram (DFD) visualizes the flow of data within the Online Voting
Management System, highlighting how data is input, processed, stored, and output across
various modules. Key features of the DFD include:

 Processes: Represented as circles or ovals, these indicate the major operations or

transformations, such as User Registration, Vote Submission, Candidate Management, and
Result Generation.

10
 Data Stores: Depicted as open rectangles, these are the system's storage locations, like the
User Database, Vote Records, and Candidate Information.
 Data Flows: Shown as arrows, they depict the movement of data between entities,
processes, and data stores. Examples include data flowing from the User to the Vote
Submission Process.
 External Entities: Represented as rectangles, these are outside actors interacting with the
system, such as Voters submitting their votes or Admins managing elections.
 Levels: The DFD can include multiple levels for deeper detail:
o Level 0 (Context Diagram): Shows the entire system as a single process with its
external entities.
o Level 1 and Beyond: Breaks down processes for a more granular view (e.g.,
registration broken into steps like data input, eligibility check, and confirmation).

11