WERABE UNIVERSITY

I N S T I T U T E OF TECHNOLOGY
DEPARTMENT OF INFORMATION TECHNOLOGY
PROJECT TITLE: WEB BASED STUDENT UNION
REPRESENTATIVE ELECTION SYSTEM FOR WERABE
UNIVERSITY

BY:
1.DAGNE GETU 0283/13
2.DEGAGA DEGEFU 0316/13
3.YADESA YEMANEH 1080/13
UNDER GUIDANCE OF
MR.SEBHADIN.N
September 2022
 WERABE UNIVERSITY
INSTITUTE OF TECHNOLOGY
DEPARTMENT OF INFORMATION TECHNOLOGY
WEB BASED STUDENT UNION REPRESENTATIVE ELECTION
MANAGEMENT SYSTEM FOR WERABE UNIVERSITY
SUBMITTED TO DEPARTEMENT OF INFORMATION
TECHNOLOGY

IN PARTIAL FULFILMENT OF THE REQUIREMENT FOR THE

DEGREE OF BACHLER OF SCIENCE IN INFORMATION
TECHNOLOGY

BY

1. DAGNE GETU…………………………...NSR/0283/13
2. DEGAGA DEGEFU……………………...NSR/0316/13
3. YADESA YEMANEH…………………....NSR/1080/13

WERABE UNIVERSITY, WERABE, ETHIOPIA

November 30 2023

This is to confirm that the project report entitled web based student union
representative election system submitted to Werabe University, Institute of
Technology Department of Information Technology in partial fulfilment of the
requirement for the award of the degree of Bachler of Science in Information
Technology is an original work carried out by Dagne Getu, Degaga Degefu, Yadesa
Yemaneh, under my guidance. The matter embodied in this project is reliable and is
genuine work done by the student and has not been submitted whether to this
University or to any other University /Institute for the fulfilment of the requirement
of any study.

Student Team Approval Form

Student Name Student Signature
---------------------------- ---------------
-------------------------- ---------------
---------------------- --- ---------------
Advisor and department head Approval Form
Advisor Name Advisor Signature
-------------------------- -------------------
Department Head Name Department Head Signature
------------------------------- ------------------
Examiner Approval Form
Examiner Name Examiner Signature
--------------------------- ----------------
----------------------------- ----------------
------------------------------ ----------------

ii

ACKNOWLEDGEMENT
First of all we would like to thank GOD for making us healthy. Without the will of the
GOD everything is impossible. Next, we will extend our thanks and appreciation to our
advisor Mr. Sebhadin.N for his volunteer to advise us and all individuals that give
important information to us. Next, we thank and appreciate our classmates and friends for
their wellness to give important information. Without the participation of individuals our
team project has no ability to reach to this stage. Moreover, we would like to thank werabe
student union president for their good approach at interview time and wellness at giving
important information for us.

iii
 Contents
Contents..............................................................................................................................................................................5
List of figures...................................................................................................................................................................7
List of Tables......................................................................................................................................................................8
CHAPTER ONE...............................................................................................................................................................11
1. Introduction...................................................................................................................................................................11
1.2. Background Information of the Organization........................................................................................................11
1.3. Background of the Project.....................................................................................................................................11
1.4. Statement of the Problem.......................................................................................................................................12
1.5. Objective of the project..........................................................................................................................................14
1.5.1 General Objective............................................................................................................................................14
1.5.2 Specific objective.............................................................................................................................................14
1.6. Feasibility Analysis................................................................................................................................................14
1.6.2 Operational feasibility......................................................................................................................................15
1.6.1 Technical feasibility.........................................................................................................................................15
1.6.3 Economic feasibility........................................................................................................................................16
.1.6.4 Behavioral/Political feasibility..........................................................................................................................17
1.6.5 Schedule feasibility............................................................................................................................................18
1.7. Scope and Limitation of the project............................................................................................................................18
1.7.1. Limitation of the project.................................................................................................................................19
1.7.2. Scope of the project........................................................................................................................................19
1.8. Significance of the Project.........................................................................................................................................19
1.9. Target Beneficiaries of the System........................................................................................................................20
1.10. Methodology for the Project................................................................................................................................21
1.4.1 Design Methodology.......................................................................................................................................21
1.10.1 Requirement Gathering Methods...................................................................................................................23
1.10.2 Requirement Modeling..................................................................................................................................23
1.11 Tools Used............................................................................................................................................................24
1.12 Risks and contingencies........................................................................................................................................25
1.13 Assumptions and Constraints................................................................................................................................25
1.14 TEAM COMPOSITION.......................................................................................................................................25
1.11.1 Time schedule of the project..........................................................................................................................26
CHAPTER TWO............................................................................................................................................................27
2.1. Introduction of Existing System............................................................................................................................27
2.2. Organization Structure...........................................................................................................................................27
2.3. Users of Existing System.......................................................................................................................................28
2.4. Major functions of the Existing System.................................................................................................................28
2.5. Existing System Workflow Structure....................................................................................................................29
2.6. Business Rules of the Existing System..................................................................................................................30
2.7. Forms and other documents of the existing systems.............................................................................................31
2.8. Bottlenecks of the existing system.........................................................................................................................31
 2.8.1 Performance (Response time)..........................................................................................................................32
2.8.2 Input (Inaccurate/redundant/flexible) and Output (Inaccurate).......................................................................33
2.8.3 Security and Controls.......................................................................................................................................33
2.8.4 Efficiency.........................................................................................................................................................33
CHAPTER 3.....................................................................................................................................................................35
3.1. Introduction............................................................................................................................................................35
3.2. Proposed System Overview...................................................................................................................................35
3.3. Functional requirements.........................................................................................................................................36
3.4. Nonfunctional Requirements.................................................................................................................................37
CHAPTER 4: System Analysis........................................................................................................................................38
4.1. System Models.......................................................................................................................................................38
4.1.1 Scenarios..........................................................................................................................................................38
4.1.2 Use Case Model...............................................................................................................................................39
4.1.3 Use Case Documentation/Description.............................................................................................................43
4.1.4 Object Model...................................................................................................................................................46
4.2. Dynamic Model.....................................................................................................................................................49
4.2.1 Sequence Diagram...........................................................................................................................................49
4.2.2 Activity Diagram.............................................................................................................................................52
4.2.3 State Diagrams.................................................................................................................................................58
CHAPTER FIVE..............................................................................................................................................................64
System Design..................................................................................................................................................................64
5.1. System Design Overview.......................................................................................................................................64
5.2. Design Considerations...........................................................................................................................................64
5.3. Design Goals..........................................................................................................................................................64
5.4. Design Trade-offs..................................................................................................................................................65
5.5. Architecture of the System.....................................................................................................................................66
5.6. System Decomposition..........................................................................................................................................67
5.7. Hardware/Software mapping.................................................................................................................................68
5.8. Persistent Data Management..................................................................................................................................69
5.9. User Interface Design............................................................................................................................................70
5.10. Object Design.......................................................................................................................................................72
5.10.1. Interface documentation guidelines..............................................................................................................72
14. References...................................................................................................................................................................73

IV
 List of figures
Figure 1: Time schedule of the project………………….……………………………………..….16
Figure 2: Use Case Model………………………………………………………………………..32

Figure 3 Class Diagram………………………………………………………………………..…………….....38

Figure: 4login sequence diagram……………………………………………………………….39
..
Figure 5: sequence diagram of view exam result…………………………………………..…….40

Figure 6: Sequence Diagram for take exam…………………………………………………….41

Figure 7: sequence diagram for vote…………………………………………………………….42

Figure 8 Activity Diagram of login...............................................................................................44

Figure 9: Activity diagram for apply for vote………………………………………………..…45

Figure 10: Activity diagram of apply for candidate……………………………………………..46

Figure 11: activity diagram for vote…………………………………………………………….47

Figure 12: state chart diagram for login…………………………………………………………49

Figure 13: state chart diagram for apply for vote………………………………………………...50

Figure 14: state chart diagram for apply for candidate…………………………………………….51

Figure 15:state chart diagram for vote…………………………………………………………….52

Figure 16: state chart diagram……………………………………………………………………..53

Figure 17: software architecture of the proposed system ..................................................................56
Figure 19: persistent diagram………………………………………………………………………………………………………………..59
Figure 19: use interface design………………………………………………………………….61

V
 List of Tables
Table 1: hard ware and material cost of the project…………………………..………………...6
Table 2: team composition……………………………………………………….…………….15
Table 3: Use Case Model table ………………………………………………………………30

Table 4: UML use case table…………………………………………………………………….31

Table 5: login use case description………………………………………………………33

Table 6: use case description for view election result…………………………………………34

Table 7: use case description of create account………………………………………………34
Table 8: use case description of view candidate………………………………………………35
Table 9: use case description of take exam……………………………………………………35
Table 10: Data dictionary of account table……………………………………………………36
Table 11: Data dictionary of student…………………………………………………………………………36
Table 12: Election date……………………………………………………………………….36
Table 13:Ballots store table……………………………………………………………………37
Table14: Exam result table……………………………………………………………………37

IV
 Abbreviations

WRU Werabe University

XAMPP cross-platform, Apache, MySQL, PHP and Perl
PHP Hypertext Preprocessor
MySQL My Structured Query Language
HTML Hyper Text Markup Language
PC Personal Computer
GB Giga byte

ABSTRACT
Web based student union representative election system of Werabe University is a system
that allows voters to elect their representative easily in election system. In web• based
student union election system, election is conducted in free and fair manner in every two
years. The president, the vice president and the general secretary can be selected every two
years. The person with the highest vote shall become the president, in addition to these chief
executives, the union has executive committees. A person who gets the second highest vote
become vice-president. Finally, a person who get the third highest vote become a secretary.
the aim of the project is to replace the manual student union representative election system
of Werabe University with web-based student union representative election system. This is
very important in different aspects such as increase security, reduces duplication of votes,
reduce loss of resources, decrease man power, reduce economical expenditure etc. in
addition to this the system is feasible in any aspects. it is designed only for Werabe University
and it is available for only the process of election. In order to develop this project first we
have collected data relating to existing manual-based system using data collection method:
like interviewing, questionary and document analysis. After that we designed the
requirement, we have collected by using Iterative and incremental model approach and
also used some analyzing and modeling tools like Edrawmax for designing. Finally, the
overall activity ofthis phase of the project work is about design and modeling of automated
student union representative election system.

Vii
 CHAPTER ONE

1. Introduction
Web based election system is a web application that allows voter can elect their representative
easily in voting systems. In online student union representative election system can be conducted
in free and fair manner in every two years in secret ballots. The president, the vice president and
the general secretary can be selected in the interval of two years. The aim of this project is to
develop web-based student union representative election system for werabe University, which
provides a way that the students can elect their representatives
1.2. Background Information of the Organization
Werabe university (WRU) is one of public higher learning institutions in Ethiopia,
established in, 2018 by of the Council of Ministers of the Federal Democratic Republic of
Ethiopia. The University is located in werabe town in zone of SNNPR Regional State. It
is located at 178 km southwest of Addis Ababa, the capital city of Ethiopia.
werabe University is undertaking researches and community service activities in
various fields to make its own contribution to a sustainable economic, social and
political development of the country. The University is planning and working on to
initiate relevant postgraduate (M.Sc. /MA) programs. After the establishment of the
university the student union election is established in the form of small manual based
system. [https:// www.wru.edu.et]

1.3. Background of the Project

The background of the project involves the need for a more efficient and accessible way to
conduct student union representative elections in a university. Traditionally, these elections may
have been conducted through paper ballots or in-person voting, which can be time-consuming
and may not be accessible to all students, especially those who are studying remotely or have
busy schedules. [(Johnson A. , 2019)]

1
Web based election system is a web application that allows voter can elect their
representative easily in voting systems. In online student union representative election
system election can be conducted in free and fair manner in every two years in secret
ballots. The president, he vice president and the general secretary can be selected in the
interval of two years
The aim of this project is to develop web-based student union representative election
system for werabe University, which provides a way that the students can elect
their representative by using web application in steady of goig physically to the election
board. It automates the existing manual activities like voter registration, candidate &
election process voting and vote counting. The project is expected to help students as
well as the university at large in overcoming the existing voting problems such as
time-consuming voting process, extravagant resource-oriented election, geographical
limited voting, and undocumented and unstructured information capture. The system
makes not only the voting process easy but also assist students by providing them with
information associated with the student union. The system is capable of improving the
user effort and time required and reduces the resource expenditure of the university.

1.4. Statement of the Problem

The statement of the problem for the project involving the implementation of a web-based student
union representative election system in werabe university can be summarized as follows:
Traditional methods of conducting student union representative elections system in werabe
university is, such as paper ballots and in-person voting, are time-consuming, less accessible to all
students, and may not effectively engage the student body. This has led to challenges in increasing
voter turnout, particularly among students studying remotely or with busy schedules. There is a
need to modernize the election process and make it more inclusive, accessible, and efficient
through the adoption of a web-based voting system.[ (Johnson A. , 2019)]

 Time consuming: The process of collecting data and entering the collected data
into the existing system consumes or take too much time to conduct. Example to
collect candidate data from each department to require much time.
 Too much paper work: since the voting system is manual, the process involves much
paper work and paper to storage, which is difficult as paper become bulky with the
student size. Example to register candidate from each department to require much
paper work and paper act as storage material.
 Loss of registration: The name of the candidate is registered on the paper, since it is
manual and the paper can be lost and it may require re-registration.
 Duplication of work: There are repetitions of works in the existing system. This
duplication of works leads to losing many resources. Example the name of the candidate
is registered on the paper, since it is manual and the paper can be lost then the
candidate register repeatedly so duplication of works can be occurred.
 Difficult to keep the student's interest: Because the system is manual, the candidate
information is not fairly verified to the student. Example candidate information can
verify to two student that select from each class from each department to elect or to be
elected the president and vice president so two students cannot be satisfied all student
interest.
 Lack of security in the existing system: Poor security system because one can get easily
the document and change whatever they want, loss of information etc. Because there
is manual unauthorized person can update, delete candidate information.
 Lack of full information about candidates: voter usually doesn't know too much detail
about the candidates in the time of election, so that they have faced problems of
identifying the candidate who is qualified to be.
Problem for searching the record of a particular voter. Problem for calculating the vote's
results.

3
 1.5. Objective of the project
1.5.1 General Objective
The general objective of the project is to design and develop web-based student
union representative election system for werabe University
1.5.2 Specific objective
The specific objectives of the proposed system are:
 .To Gather requirements.
 To identify and analysis the problem with current system and functional and
nonfunctional requirement of new system.
 To Design the proposed system including the system
architecture.
 To Develop/Implement a prototype election/voting system.

1.6. Feasibility Analysis

The feasibility study of the project involving the implementation of a web-based student union
representative election system in a university would typically assess the technical, economic, and
operational aspects of the proposed system. The study would aim to determine whether the project
is viable and practical to undertake.[ (Johnson A. , 2019)]
Generally, the feasibility study aims to provide answers to the following
issues.
Is easy to operate?
Does the return on investment justify the project and running
costs? Is the system easier for maintenance?
Is the system compatible with the legal, political and social requirements of society in
general and that of Werabe University and the country in particular?

4
1.6.2 Operational feasibility
Operational feasibility measure of how well the solutions for problems will work in
the association. the system is operationally feasible and improves the current operations
of the association. It is a good solution maker of the problem or specific solution will
work in the existing system and create a good environment towards the user of the system.
In addition to
this:
 It provides efficient resource needed for its implementation.
 The system is accepted and supported by the users and site viewers.
 The system will minimize the time and man power needed to give fast and secure service
to the users.

1.6.1 Technical feasibility

Technical Feasibility is concerned with specifying the equipment's and software that will
successfully satisfy the user requirements. It is the measure of practicality of the specific
technical solution and the availability of technical resources and expertise. This system
has been implemented by technical computer science students. so, the development of the
new system is technically feasible.
The proposed web-based student union voting system is technically feasible. In order to
ensure whether the system is technically feasible or not, the system should specify the
following cases:
The software currently possesses the necessary technology: Because it achieves the
required goal, as much as possible we tried to encounter all hardware and software
requirements and also the technology is easily available and deployed everywhere.
The new system posses' necessarily technical experts: In this project the team uses
languages such as HTML, PHP, java script and CSS to develop the new system. Example
to control double voting using voting states when the voter vote on candidate then the vote
states can be voted. So once the module is developed it can be easily held and accessible
by non-technical person who have basic computer skill without the involvement of the
developer, so it doesn't require any technical expertise.

5
 1.6.3 Economic feasibility
The current system used by the student union election result in enormous expenditure on
paper, pen, time and other costs due to improper mechanism to deal with the customer information.
Comparison of the projected costs with the potential benefits, such as increased voter turnout
and improved efficiency in the election process.
The proposed system resolves these additional requirements and expenditures.
The economic feasibility of the purposed system determined by cost of project.
 Cost of the project
The cost of the project should be calculated before diving in to the development of the project.
Calculating the cost of the project is very important to check whether the system is feasible
economically or not. So, the cost of the proposed system is shown below.
 Software cost of the project
The software costs those we use are freely downloaded from the internet. So the cost of software
is zero.
 Hard ware and material cost of the project
Table 1: hard ware and material cost of the project
No Items Quantity Unit price(in birr) Total price ( in birr)

1 Pen 3 25.00 75.00

2 Paper(A4) 1pack 150.00 150.00
3 Flash(4GB) 1 200 200
4 PC 1 20,000 20,000

5 Document - 500.00 500.00

Printing per
6 Total 8 - 20925

Total cost of the project=software cost+ hardware and material cost

Total cost=0+20925=20925
So, the proposed system is economically feasible.

6
 Tangible benefits
The system has Tangible benefits
such as:
 Cost Reduction
 Error Reduction
 Increase Speed of activity
 Intangible benefits
The system has intangible benefits
such as:
 Reduce Resource Consumption.
 Increase Security, reliability and.
 Decrease workload of the union. Improving resource utilization.
 Increase flexibility of student union
.1.6.4 Behavioral/Political feasibility
The behavioral and political feasibility of implementing a web-based student union representative
election system can be assessed through various factors:
1. Behavioral Feasibility:
- User Acceptance: Assessing whether students, faculty, and staff are willing to use an
online platform for the election process. This may involve conducting surveys, focus
groups, or pilot tests to gauge their comfort with digital voting.
- Technical Proficiency: Evaluating the technological literacy of the university community to
ensure that they can navigate and use the online election system effectively.
- Accessibility: Ensuring that the web-based system is accessible to all eligible voters,
including those with disabilities or limited access to technology.

7
2. Political Feasibility:
- Stakeholder Support: Assessing the support of key stakeholders such as the university
administration, student union, faculty members, and relevant committees for the transition
to a web-based election system.
- Regulatory Compliance: Ensuring that the online election system complies with university
regulations, student union bylaws, and any relevant legal requirements.
- Transparency and Security: Addressing concerns about the security and transparency of
the online voting process to maintain the integrity of the election and gain political buy-in
from stakeholders.
1.6.5 Schedule feasibility
Schedule feasibility in the context of implementing a web-based student union representative
election system in a university refers to the practicality and achievability of the timeline for the
project. It involves assessing whether the proposed schedule for developing, testing, and deploying
the online election system aligns with the university's academic calendar, administrative processes,
and any relevant deadlines.
Key considerations for schedule feasibility may include:
1. Academic Calendar: Ensuring that the election schedule does not conflict with major academic
events such as midterms, finals, or breaks, which could affect voter participation and engagement.
2. Administrative Processes: Aligning the election timeline with the university's administrative
processes, such as budgeting, procurement of necessary resources, and coordination with relevant
departments or stakeholders.
1.7. Scope and Limitation of the project
The scope of the project refers to the area, where the ongoing system is applied and how
much it is powerful to solve the problem. It also shows that how the specified specific
objective achieves by the project. So, this project focuses on web-based student union
election system which is available for only Werabe University. The system authenticates
and validates the user by using username and password. It is does not manage activities that
the union members do after they are elected if the duty is not election process. Means it is
use for only the process of election.

8
 1.7.1. Limitation of the project
Limitation of the project is the drawback that can be occur on the function of the project.
Limitations are the necessary tasks that the given system must include, but are not included due
to
different factors. Due to Shortage of time, Lack of reference materials, lack of
knowledge, lack of information from the organization and others, the system faced to the
following problems.
The system uses only English language.
The system cannot have Security camera when candidate take online exam In which
the candidate takes to be elected by the students.
The system does not solve a problem occurred, during more than one candidate get the
same number of votes.
1.7.2. Scope of the project
The scope of the project refers to the area, where the ongoing system is applied and how
much it is powerful to solve the problem. It also shows that how the specified specific
objective achieves by the project. So, this project focuses on web-based student union
election system which is available for only werabe University. The system authenticates and
validates the user by using username and password. It is does not manage activities that the
union members do after they are elected if the duty is not election process. Means it is use
for only the process of election.
1.8. Significance of the Project
The significance of the project means the important role of the project to all the societies, the
users and to the concerned bodies. after completion of the proposed system, it will deliver the
following benefits for the process of election takes place in the university.
- It eliminates voting repetition, while the voting will be taking
place.
- It eliminates the geographical limitation by making vote from anywhere in the
University.
- It enables the administrator to update, delete and edit information about the voter
and candidate

9
 Any voter who has a local area network connection can make his/her sound to be
heard equally his/her vote to the preferred candidate.
Resource and finance expenditure in terms of meeting-oriented costs will be saved and
the student union can use that for another essential works such as disable student that
can be supported by the student union in terms of financial resources.
Error of counting of votes will not occur, because the system assures that counting is
done automatically so that there are no voting frauds at all.
Increases accuracy and availability and quality of the voting process and number of voters
as individual will find it easier and more convenient to vote.
- It provides distributed and equal information through online for all voters (students)
and
- Information is available in a desired time.
- Increase the security of votes.
- It gives private online election process
- To distinguish the candidates by their profile and specific information.

1.9. Target Beneficiaries of the System

Students: the primary beneficiraries of the system are students who are able to easily access
information about their student union representatives, submit feedback or concerns, and participate
in election and decision-making process.
Student union representative:
The system allows student union representatives to efficiently manage their roles, communicate
with their constituents, and organize events and inititives.
University administration:
By having a centralized platform to oversee and support student union activites and to ensure that
the representatives are fulfilling their responsibilities effectively.
Faculty and staff:
By providing a channel for communication with student union representatives and a means to
collaborate on projects or initiatives.
10
 1.10. Methodology for the Project
1.4.1 Design Methodology
From system development model we use iterative and incremental development model. The
reason we choose this is, this model develops a system through building small portions of all
the features. This helps to meet initial scope quickly and release it for feedback.
In this model, start off by implementing a small set of the software requirements. These are
then enhanced iteratively in the evolving versions until the system is completed. This process
model starts with part of the software, which is then implemented and reviewed to
identify further requirements.
The iterative model allows to see the results at the early stages of development. This makes it
easy to identify and fix any functional or design flaws. It also makes it easier to manage risk
and change requirements.
The iterative model is a good choice for large software that can be easily broken down into
modules as shown in the diagram below.

11
 Requirement
]ate] gathering and
analaysis

System
analysis

System design

Implementatio
n

System testing

Maintenace

Figure 1: Design Methodology

12
1.10.1 Requirement Gathering Methods
To design and develop web-based student union voting system for Werabe student, we used
the following methods to gather information about the current system and alternate ways
to develop the new system.
Interview: To collect information from the president of the student council and
executive members of the union.
Questioner: To get full information about the election process we prepare the Questions
by the document form.
Direct Observation (primary method) by watching what student do or by
obtaining relatively objective measures of how student behave in work situation, we
would have first• hand and accurate appreciation of what they really doing or how they are
doing it.
Document analysis (literature review): Study the document that is written
before.
1.10.2 Requirement Modeling
Requirement modeling refers to the process of capturing and documenting the requirements of a
system. It involves identifying various stakeholders, understanding their needs and expectations,
and defining the functionalities and features that the system should possess.
In the context of a web-based student union representative election system, requirement modeling
would involve:
Identifying stakeholders: This includes students, faculty members, administration staff, election
committee members, and other relevant parties involved in the election process.
Gathering requirements: Conduct interviews, surveys, or workshops with the stakeholders to
understand their needs and expectations from the system. This could include features such as online
candidate registration, voter registration, secure and anonymous voting, result tabulation, etc.
Creating use cases: Use cases are scenarios that describe how users interact with the system. For
example, a use case could be "A student registers as a candidate for the election." These use cases
help in understanding the system's functionality from a user's perspective.

13
Defining system requirements: Based on the gathered information, define the functional and
non-functional requirements of the system. Functional requirements specify what the system
should do (e.g., allow students to vote online), while non-functional requirements specify the
system's qualities (e.g., security, performance, usability).
1.11 Tools Used
To develop the proposed system, we would use different software and hardware
components.
Hardware requirement:
The hardware requirements or just requirements are the requirements of a hardware device.
Hardware requirement include:
- Personal computer:-used to write documentation and implementation.
Processor Intel(R) core (TM)i3-4160 CPU@ 3.60 GHz
- RAM-3.24GB.
- Flash Drive-32GB: required for data movement.
- Stationeries(pen, paper).
Software requirement:
The software requirements specification is the single most important document in the
software development process. It provides the basis for development as well as for validation.
The following are software requirement:
WAMP Server version 2.2.17: manage servers setting. The reason of selecting WAMP server
are secure means they are not easily attack by virus when we compare to other servers.
Wonder share edrawmax: used to draw different UML those are necessary to structure the
system. E.g. Activity Diagram, Class Diagram, Sequence Diagram and Use case Diagram.
Because it is easy to use and understand.
- Notepad++ version 7.5.9.0.
- Operating System - Windows 10.
- Browser: internet explorer or Firefox.
- PHP version 7.0.9: it is server-side programming language used to learn how to make
- PHP interact with WAMP server on our system to deliver instant content.
- It is popular and widely used [8].
- Easier to fix problems [8].

14
 HTML: client-side programming language used to create web content. so, it can be
displayed by a web browser.
CSS: client-side programming language used for the formatting of the system. it defines
the style of a website's content.
JavaScript: client-side programming language used for animation, validation purpose and
to display dialog box.

1.12 Risks and contingencies

When the system starts being developing various risks may happen due to different factors.
These risks may be high costs, data security, system downtime, lack user adoption, budget,
resource constraints and others. This risk may result undesirable outcome so in order to
minimize and solve the problems, a risk contingency method will be applied by creating clear
project parameters and communicating with the concerned bodies.

1.13 Assumptions and Constraints

Assumptions :
The student union representative election will be well-received by the university and will
lead to increase engagements and communication.
The system will be user-friendly and accessible to all students, regardless of technical abilities
Constraints:
Ensure that system gives much better service the current system

1.14 TEAM COMPOSITION

N Name of developers Responsibilities

o1 DAGNE GETU System design , analysis and implementation

2 DEGAGA DEGEFU System requirements and implementation

3 YADESA YEMANEH Gather information and implementation

15
1.11.1 Time schedule of the project
Figure 1: Time schedule of the project

16
 CHAPTER TWO
2.1. Introduction of Existing System
The existing system for student union representative elections often involves a manual and paper-
based process, which can be time-consuming, labor-intensive, and prone to errors. Typically, the
process includes physical nomination forms, campaign posters, and in-person voting at
designated locations. This traditional method may also lack transparency and accessibility for all
students, as well as make it challenging to manage the entire election process efficiently.
Moreover, the existing system may face logistical challenges, such as coordinating multiple
polling stations, managing and counting paper ballots, and ensuring the security and integrity of
the election results. Additionally, the manual process may limit the ability of students to access
comprehensive information about candidates and their platforms, potentially impacting the
informed decision-making process.

2.2. Organization Structure

In a web-based student union representative election system at a university, the organizational
structure may be as follows:
Election Committee:
- Faculty members
- Student representatives
- Administrative staff
Candidates:
- Students running for student union representative positions
Voters:
- The student body
System Administrators:
- IT professionals responsible for managing and maintaining the web-based election system

17
Communication Channels:
- Official university communication channels for disseminating election-related information
Dispute Resolution Mechanism:
- A designated body or process for handling disputes and complaints related to the election
process
Data Management Team:
- Personnel responsible for managing voter registration data, candidate information, and
election results
Support Staff:
- Individuals providing technical support and assistance to candidates and voters

2.3. Users of Existing System

Users of the existing system are:
- Candidate: who is the member of our university student and candidate for this
election to represent student.
- Voters/students: are regular student that learns in the university c u r r e n t l y and
those who apply to vote his/her representatives in the election system.
- Student service directorate: one who register discipline student.
- Registrar: one who register student information.
2.4. Major functions of the Existing System
The major functions of an existing system typically include:
- Candidate Registration: The system allows eligible students to register as candidates for
various student union representative positions. Candidates can provide their personal
information, campaign platforms, and other relevant details through the online platform.
- Voter Registration and Verification: The system facilitates the registration of eligible
voters and verifies their eligibility to participate in the election. It may involve validating
students' enrollment status and other criteria to ensure that only qualified individuals can
cast their votes.

18
 - Secure Online Voting: The system provides a secure and user-friendly online platform for
eligible voters to cast their votes. It ensures the confidentiality and integrity of the voting
process while preventing fraudulent or duplicate votes.
- Security and Integrity: The system ensures the security and integrity of the entire election
process, including data protection, secure access controls, and measures to prevent
tampering or unauthorized access to the system.

2.5. Existing System Workflow Structure

The workflow structure of an existing system typically follows a series of steps to ensure a
smooth and transparent election process. Below is a general outline of the workflow structure:
Announcement and Nomination:
The university announces the upcoming student union representative election.
Eligible students are invited to nominate themselves as candidates for various positions.
Candidate Registration:
Candidates are required to register their candidacy through the web-based election system.
They may need to provide personal information, a candidate statement, and possibly
endorsements from fellow students.
Voter Registration:
The system allows eligible students to register as voters for the election.
This may involve verifying their student status and ensuring they meet any other eligibility
criteria.
Campaigning Period:
Once candidates are approved, a campaigning period begins.
Candidates use the web-based system to promote their platforms and engage with potential
voters.
Voting Period:
The system opens for a specific period to allow registered students to cast their votes.
Security measures are in place to ensure the integrity and confidentiality of the voting process.

19
Vote Tallying:
Once the voting period ends, the system tallies the votes and generates the election results.
Result Announcement:
The system publishes the election results, including the winners for each position.
Transition:
The newly elected student representatives begin their transition into their roles, potentially using
the web-based system to communicate with university administrators and plan their activities.

2.6. Business Rules of the Existing System

A business rule is effectively an operating principle or policy the software must
satisfy. It often relevant to access control issues, business calculations, or operating
policies and principles of the organization. Therefore, our new system has the
following business rules.
BRl: The Candidate should be member of werabe University achieved by
candidate id.
BR2: The candidate and voter should have only regular student to
participate in election.
BR3: one voter selects only one candidate at election time president, vice
president or secretary.
BR4: Candidate should have CGPA greater than or equal to CGPA 3.0 to
be the member of the candidate.
BR5: In order to be the member of the candidate the user must first take
exam and must score greater than 50%.
BR6: The voter must apply and vote with in the specified range of time.
BR7: The candidate must apply for vote and take exam with in the specified
range of time.
BR: in order to be the member of the voter or candidate the user must apply request
to the administrator.

20
 2.7. Forms and other documents of the existing systems
The following forms and documents may be part of the existing system:
Nomination Form: A form that allows students to nominate themselves or others as candidates
for various positions in the student union.
Candidate Information Sheets: Documents containing information about each candidate,
including their manifesto, qualifications, and other relevant details.
Voter Registration Form: A form that allows students to register as eligible voters for the
election.
Election Rules and Regulations: A document outlining the rules and regulations governing the
election process, including eligibility criteria, campaigning guidelines, and voting procedures.
Results Declaration: A document or web page displaying the final results of the election,
including the names of the elected representatives and the vote counts.
Complaint Form: A form that allows students to lodge complaints or raise concerns about any
aspect of the election process.
Voter Guide: A document or web page providing information on how to access the online voting
platform, key dates, and instructions for casting votes.
Election Timeline: A document outlining the schedule of events, deadlines, and important dates
related to the election process.

2.8. Bottlenecks of the existing system

While web-based student union representative election systems offer numerous benefits, they
may also face certain bottlenecks and challenges. Some potential bottlenecks in the existing
system include:
Technical Issues: The system may experience technical glitches, such as server outages, slow
loading times, or compatibility issues with certain devices or browsers, which can disrupt the
registration and voting processes.

21
Security Concerns: Ensuring the security and integrity of the online voting process is crucial. The
system must guard against potential cyber threats, such as hacking, unauthorized access, or
tampering with voter data or election results.
Verification Process: The verification of candidate eligibility and voter registration can be a
bottleneck if the system lacks efficient methods for confirming the identity and status of
participants, leading to delays or inaccuracies in the registration process.
Accessibility: The system may face accessibility challenges for students with disabilities or those
who have limited access to technology, potentially excluding them from participating fully in the
election process.
Engagement and Communication: Maintaining effective communication between candidates,
voters, and election administrators can be a bottleneck if the system does not provide adequate
tools for disseminating information, addressing queries, and resolving issues in a timely manner.
Data Management: Managing a large volume of candidate profiles, voter registrations, and
election results can become a bottleneck if the system lacks efficient data management
capabilities, potentially leading to errors or delays in processing information.

2.8.1 Performance (Response time)

The performance, specifically the response time, of a web-based student union representative
election system in a university can vary based on several factors, including the technical
infrastructure, server capacity, network bandwidth, and the number of concurrent users accessing
the system.
Concurrent Users: The number of simultaneous users accessing the system can impact response
time. The system should be designed to handle a large number of users without significant
degradation in performance.

22
System Design: The efficiency of the system's code, database queries, and overall architecture
can influence response time.
To ensure optimal performance, thorough testing and performance tuning should be conducted
before and during the election period. Load testing, stress testing, and monitoring tools can help
identify potential bottlenecks and areas for improvement.

2.8.2 Input (Inaccurate/redundant/flexible) and Output (Inaccurate)

- Inaccurate: Students are allowed to vote multiple times without proper validation mechanisms,
leading to the potential for inaccurate results and voter manipulation.
- Redundant: The system collects excessive personal information beyond what is necessary for
the election process, unnecessarily burdening students and posing privacy risks.
- Flexible: The system offers overly flexible criteria for candidate submissions, leading to
potential inaccuracies and lack of verification of candidate eligibility.
Output (inaccurate):
- Inaccurate: The election system may produce inaccurate results due to unverified multiple
voting instances or inadequately scrutinized candidate details, ultimately leading to a lack of
confidence in the outcome.

2.8.3 Security and Controls

The current system may face accessed by an authorized person.
Voter Verification:
- Deploy identity verification measures to ensure that each voter is a legitimate student of the
university, thereby preventing unauthorized individuals from participating in the election process.

2.8.4 Efficiency
The efficiency of a web-based student union representative election system in a university refers
to its ability to facilitate a smooth, streamlined, and high-performing election process while
optimizing resource utilization and minimizing unnecessary delays. Here are some key aspects of
efficiency in such a system:
User-Friendly Interface:

23
 - An intuitive and user-friendly interface that simplifies the voting process, reduces the
likelihood of errors, and minimizes the need for extensive user training.
Scalability:
- The system should be capable of handling an increasing number of concurrent users during
peak voting periods without experiencing significant degradation in performance.
Response Time:
- The system should deliver rapid response times to ensure that voters, candidates, and
administrators can access and interact with the system without enduring excessive delays.
Resource Optimization:
- Efficient utilization of computing resources to handle voting loads without overloading servers
or leading to system slowdowns.
Reliability:
- Dependable availability and uptime to prevent system outages and ensure that users can
access the election system throughout the voting period.
Real-Time Reporting:
- Provision of real-time updates on the election progress, vote counts, and interim results,
enabling transparency and timely communication of election status to stakeholders.

24
 CHAPTER 3
Proposed system
3.1. Introduction
The proposed web-based student union representative election system aims to modernize and
streamline the election process at our university, making it more accessible, efficient, and
transparent for all eligible students. By leveraging web-based technology, the system will allow
for online candidate registration, voter registration, and secure online voting, eliminating the need
for traditional paper-based processes. This will not only reduce administrative burden but also
enable more students to participate in the election regardless of their physical location on
campus.
The proposed system's introduction will bring greater accessibility, transparency, and efficiency
to the student union representative election process, fostering a more inclusive and participatory
environment within our university community.

3.2. Proposed System Overview

The proposed system i s about web-based student union election system for werabe university
In this web-based student union election
system:
1. SSD posts their notice where CGPA >= 3.00 can act as a candidate and can be
elected.
2. Then the candidate creates their account and send request to
admin.
3. Then admin approve the request based on the given
criteria.
4. The candidate login within that account and take
exam.
5. Then if they pass the exam they are considered as the candidate and post their
promotion.

6. After that the voter creates their account and send request to
admin
 25

7. Admin approves the request based on the given

criteria

8. Then the voter login within their account and view the candidate promotion finally the
voter can vote.
Web based student union election system is expected to help University as well as the
students at large in overcoming the existing voting problems such as time-consuming
voting process, extravagant resource-oriented election, geographical limited voting by
using id, and undocumented and unstructured information capture. The system makes
not only the voting process easy but also assist students by providing them with
information associated with the student union.
The system is capable of improving the user effort and time required and reduces the
resource expenditure of the University.

3.3. Functional requirements

The functional requirements of the system describe the necessary functions for which the
system is expected to fulfill. The requirements specified are helpful to clearly understand
the scope and the objective of the system, and consequently this will be helpful for
designing the system effectively. Functional requirements are intended behavior of the
system. This behavior may be expressed as services, tasks or functions the system is
required to perform
- The proposed system meets the following functional requirements: •

- The system should create new account for

users.
- She system shall prevent the user from voting more than
one's.
- The system should allow to login to the system only authenticated
users.
- The system should validate and authenticate the users' username and
password.
- The system should register candidates, and voter.
 26

- The system should evaluate the performance of the user who requests apply for
candidate by using online exam and send their exam result.
- The system shall calculate total number of votes for each
candidate.
- At the end of the election, the system allows generate report of the
election.
Generally, the system shall allow create account, search account, update account view
account, block account, take backup, restore backup, view report, approve account request for
voter and candidate, view candidate, view promotion, view notice, send student data, view
promotion, view voter, view exam result, take exam, send account request, post
promotion, give feedback, view election result, view student data, prepare exam question, set
exam date, update student apply date, set student apply date, submit discipline student, add
notice, and manage feedback.
3.4. Nonfunctional Requirements
Nonfunctional requirement is one of the system requirements which the proposed system
should include such as security, availability, and performance etc. Those are requirements that
are not directly concerned with the specific functions delivered by the system. The following
are the non-functional requirements that the proposed system possessed.
Security: The system authenticates users by using username and password.
Performance: Since the system is web based, the deliver response time of the system should
be very fast (1.9GHz). It performs its activity that are relating to the vote
Accurately.
Usability: this system allows all students to participate in election easily with any place in the
universe.
Availability: The system should be available for access at restriction day and time at election
set by SSD. And also, the interaction between the voters and the system is more than enough
to know about the union and the election process.
 27

CHAPTER 4: System Analysis

4.1. System Models
4.1.1 Scenarios
 Use case model: The system model would outline the different use cases of the web-
based student union representative election system, such as registering as a candidate,
casting a vote, and viewing election results. This model would help to identify all the
possible interactions and functions of the system.
 Activity diagram: The system model could include an activity diagram showing the
different steps involved in the election process, such as candidate registration,
campaigning, voting, and result declaration. This diagram would help to visualize the
flow of activities in the system.
 Sequence diagram: A sequence diagram could be used to represent the interactions
between different components of the system during the election process, such as a voter
casting a vote, the system verifying the vote, and updating the election results. This
diagram would help to understand the sequence of events in the system.
 Class diagram: The system model could include a class diagram showing the different
classes and their relationships in the system, such as voter, candidate, election, and voting
system. This diagram would help to understand the structure of the system and its
components.
 State diagram: A state diagram could be used to represent the different states that a voter
or a candidate can be in during the election process, such as registered, voting, or elected.
This diagram would help to visualize the possible states and transitions in the system.
 28

4.1.2 Use Case Model

Use case modelling is a simplified abstract, generalized use case that captures the intentions of
the user in a technology and implementation independent manner. Use case diagrams show the
various activities that the users can perform on the system. The system is something that
performs a function. They model the dynamic aspects of the system. A use case diagram
illustrates a set of use cases for a system, the actors of these use cases, the relations between the
actors and these use cases, and the relations among the use case. It identifies use case and actors
of the proposed system. it is the functional behaviour of the system as seen by the user.
Generally, use case diagram contains four components.
Use case: Use cases are a set of actions, services, and functions that the system needs to perform.

G-
Actor: An actor represents a type of users of the system or external system that plays a role in one
or more interactions with our system.

Boundary: it is the system of interest in relation to the world around it.

Relationships: Shows the communication between actor and the use case and the relationship
between use cases.

✓ Association between actor and use case described by solid line.

 29

✓ Extend: used when there are alternative options in a certain use case.

<< Extend >>

< ----------------

include: indicates one use case is necessary by another perform an operation.

<< Include >>

------------------------->

Actor Description

Table 3: Use Case Model table

Admin This actor who control and manage the

systems.
candidate Is an actor who has the member of our
university student and elected by voter.
Voter Those who are regular students that learns in
the university currently and those who apply
to vote his/her representatives in the election
time.
Main registrar The act or who submits student data which
are regular students to the system
Student service director The actor who submit student discipline
record.

Use case identification Use case: A use case describes a sequence of actions that provide a
measurable value to an actor. A use case is drawn as a horizontal ellipse on a UML use case
diagram.
 30

Table 4: UML use case table.

ID Use Case Name Use/Include

UCl Login
UC2 Approve student account UCl
UC3 Create account UCl
UC4 Update account UCl
UC5 block account UCl
UC6 View account UCl
UC7 Take backup UCl
UC8 Restore backup UCl
UC9 View feedback UCl
UClO Delete feedback UCl
UCll Post promotion UCl
UC12 View election result UCl
UC13 Take exam UCl
UC14 vote UCl
UC15 View exam result
UC16 View candidate
UC18 Add notice UCl
UC19 View notice
UC20 Submit student discipline record UCl
UC21 Set student apply date UCl
UC22 update student apply date UCl
UC23 Set exam date UCl
UC24 Prepare exam question UCl
UC25 Submit student data UCl
UC26 View promotion
UC27 Send account request UCl
UC28 Give feedback UCl
UC29 View student data UCl
UC30 View Report
UC31 Logout UCl
31
Figure 2: Use Case Model

32

4.1.3 Use Case Documentation/Description

The following consecutive tables show the use case description for each of the use cases. Each
table contains the use case name, the actor which initiates and interacts with the use case,
description of the use case and typical course of events that show the interaction between the
actor and the use case which enable the team to easily depict the functions of the proposed
system.
Table 5: login use case description

Use case ID UCl

Name Login

Actor user

Description This describes how the users log into the system.

Precondition Users of the system should have user name and password.

Basic course of action 1. Open web site.

2. User enters username and password.

3. Click login button.

4. System verifies username and Password.

5. If username and password is valid.

6. User authenticated and gets access to the system.

7. Use case ends.

Alternative course of 1. User is not authenticated and is denied access to the system.
action
2. System displays an incorrect username and password message.

3. System enables user to try again 4 times and wait for a few
second.
 4. Use case returns to step 2 to fill the correct username and
Password

Post condition Login in to the system successfully.

33
Table 6: use case description for view election result
Use case ID UC12

Name View election result

Actor Voter, candidate, student service director
Description This describes the process of how the user views the election
results by using the system.
Precondition Time must be run over the limit
Basic course of action 1. The user must be open website.
action
2. The user can ask information they want to know.

3. After searching necessary information click on view

button.

4. After getting necessary information they can view.

5. Use case end.

Alternative course of action If all users can't see the result of the election, try again and
login to the system
Post Condition The user knows the wanted information.

Table 7: use case description of create account

Use case ID UC3

Use case name Create account

Actor Admistrator
Description the system administrator create account for authorized users
to the System.
Pre-condition System administrator must login and should manually get
list of eligible users' information first.
Basic course of action(flow 1. Clicks on register link action (Flow of
events) 2. Registration form displayed
event):
3. Enter user's profile ... With use name & password.
4.System administrator clicks on register button
5. validate data entry
6. Display successfully registered message.
7. Use case ends
Alternative course action 1. If the data entry not valid, system displays invalid Input
message.
2. If user has been already registered, user registered
 message displayed.
Post-condition The System Administrator created account so users can
login the system.

34

Table 8: use case description of view candidate

Use case ID UC16
Use case name View candidate

Actor Voter, student service director, candidate.

Description This describes the process of how the user views the candidate
information by using the system.
Pre-condition Candidate must fulfil the required information and rules.

Basic course of action 1. The user must be open website.

2. The user can ask information they want to know.
3. After searching necessary information click on candidates
view button.
4. After getting necessary information they can view.
5. Use case end.
Alternative course action If all users can't see the candidates' information, try again and
login to the system.
Post-condition The user knows the wanted information.

Table 9: use case description of take exam

Use case ID UC13
Use case name Take exam
Actor Candidates
Description This use case describes how the candidate to login into the System
to takes exam.
Pre-condition The user must have username and password.
Basic course of action 1. Open web site.
2. User enters username and password.
3. Candidate enter exam password.
4. Click login button.
5. System verifies username and Password and exam password.
6. If exam password, username and password is valid candidate
authenticated and takes Exam on the system.
8. Use case ends.

Alternative course action 1.User is not authenticated and is denied access to the system.
2.System displays an incorrect username and password message.
3.System enables user to try again.
4.Use case returns to step 2 to fill the correct exam password,
 username And password

Post-condition User gets access to the system according to their predefined system
privileges.
35

4.1.4 Object Model

4.1.4.1 Data Dictionary

Table 10: Data dictionary of account table

Field name Data type Size Description

user id Int 20 Holds the id of the user

First_name Varchar 20 Holds the type of the First_name

last-name Varchar 20 Holds the of the last-name

Sex Varchar 20 Holds the value of the Sex

Age Int 10 Holds the value of the Age

User name Varchar 20 Holds the value User name

password Varchar 15 Indicate the password

role Varchar 20 holds the value of user role

status Varchar 20 Indicates the Status of the user

Table 11: Data dictionary of student table

Field name Data type Size Description

Student_id int 15 Holds the value of student id

First_name varchar 20 Holds the value of student
First_name
last-name varchar 20 Holds the value of student last-
name
gender varchar 15 Holds the value of student gender
age Int 10 Holds the value of student age
college varchar 20 Holds the value of student college
department varchar 30 Holds the value of student
department
year int 15 Holds the value of student year
CGPA float 15 Holds the value of student CGPA

Table 12: Election date

Field name Data type Size Description
Election date_id int 20 Holds the value of Election date_id
Start date Date 20 Holds the value of Start date
Close date Date 20 Holds the value of Close date

36

Table 13:Ballots store table

Field name Data type Size Description

Voter_id int 20 Holds the value of Voter_id

Candidate_id Int 20 Holds the value of Candidate_id

Table14: Exam result table

Field name Data type Size Description

Candidate_id Int 50 Holds the value of Candidate_id
Total questions Int 100 Holds the value of Total questions
Correct Int 100 Holds the value of Correct
Incorrect Int 100 Holds the value of Incorrect
Total Int 100 Holds the value of Total
status Varchar 20 Holds the value of status

4.1.4.2 Class Diagram (Conceptual Modelling)

Class diagram in the Unified Modelling Language (UML) is a type of static structure diagram
that describes the structure of a system by showing the system's classes, their attributes,
operations (or methods), and the relationships among objects. In this class diagram the team
members try to describe the types of objects in the system and the various kinds of static
relationships that exist among them as well as depicted the detailed understanding of problem
domain of the system. These Class diagrams are developed based on the functional requirement.
.
 37

WEB BASED STUDENT UNION SYSTEM CLASS DIAGRAM FOR WERABE UNIVERSITY

Create

1 1 1

*
Admin
Login
User username:varchar(100)
-user id:int() Account
+login() -username:varchar(100) -password:varchar(50)
Inherit -fname:varchar(20) 1 1
+approved student -role:varchar(30)
-lame: varchar(20) -password:varchar(50)
account
-sex:varchar(20) -role:varchar(30)
+create account() +login()
-age:varchar(20)
+logout() inherit +logout()

inherit manage inherit inherit

manage

Candidate Voter
SSD -collage:varchar(20)
-collage:varchar(20)
Main Resistor -department:varchar(20)
-department:varchar(20)
+login()
-year:varchar(20) -year:varchar(20)
+add notice() 1 1 +login()
-cgpa:varchar(20) -program:varchar(20)
+prepare exam() +send student data()
Send notification -program:varchar(20) +login()
+set election date() +view notification()
-photo:longtext +vote()
+logout() +logout()
+login() +view candidate()
+send student data() +view promotion()
+view notification()
restrict 1 send
+logout()
1 *

view * 1 1

* 1 take post send

1 view
Election Date
Notice * * *
-election:id(11)
Question Promotion
-started date:date time -id:int(11) -qid:int(11) -qid:int(11)
-closed date:date time Request
-myfile title:varchar(30) -question:varchar(255) -date:date view
-date:date -option A:varchar(100) -ex-date:date
-request
-ex-date:date -option B:varchar(100) -content:longtext
varchar()type:var
-option C:varchar(100) -title:varchar(300)
char
-option D:varchar(100)
-date:date
-txtanswer:varchar(100)
prepare

Approve *

Figure 2 Class Diagram 38

4.2. Dynamic Model

4.2.1 Sequence Diagram

UML Sequence diagram showing the sequence of interactions among objects and used to
represent or model the flow of messages, events and actions between the objects or components
of a system.
Sequence diagrams are also used primarily to design, document and validate the architecture and
interfaces of the system by describing the sequence of actions that need to be performed to
complete a task or scenario.
Figure 3: login sequence diagram

39

Figure 4: sequence diagram of view exam result

 40

Figure 5: Sequence Diagram for take exam

 41

Figure 5: sequence diagram for vote

4.2.2 Activity Diagram

Activity diagrams are used to document the logic of a single operation/method, a single use case,
or the flow of a business process. Activity diagrams essentially a flowchart showing flow of
control from activity to activity. However, activity diagrams can also show parallel or concurrent
flows and alternate flows. It includes modelling the sequential process. It also includes modelling
the flow of an object as object as it moves from one state to another state at different points in the
flow of control.

42

In activity diagram uses activity nodes and activity edges to model the flow of control and data
between actions. And it is helpful in the following phases of a project:
• Before starting a project, activity diagrams used to model the most important workflows.
• During the requirements phase, to illustrate the flow of events that the use cases describe.
• During the analysis and design phases, to define the behavior of operations.
The following are some of basic activity diagram notation and symbols.
Initial State or Start Point: represents the initial action state or the start point for any activity
diagram.
Start Point/Initial State

Activity or Action State: An action state represents the non-interruptible action of objects.

Activity Activity Activity

Action Flow: Illustrate the transitions from one action state to another

Action Flow

Decisions and Branching: A diamond represents a decision with alternate paths. When an activity
requires a decision prior to moving on to the next activity, add a diamond between the two
activities

Decision Symbol

Final State or End Point: An arrow pointing to a filled circle nested inside another circle

represents the final action state.

 End Point Symbol

43

Figure 6: Activity Diagram of login

 44

Figure 7: Activity diagram for apply for vote

45
Figure 8: Activity diagram of apply for candidate

46
Figure 9: activity diagram for vote

47
Figure 10: activity diagram for create account

4.2.3 State Diagrams

As the name suggests that state chart diagrams depict the various states that an object may be in
and the transitions between those states. It used to model the lifetime of an object from creation
to termination and describes the flow of control from one state to another state. The main usage
of state chart diagram is described below.
• To model the object states of an object
• To model the reactive system which consists of reactive object
• To identify the events for state changes

48
Figure 11: state chart diagram for login

49
Figure 12: state chart diagram for apply for vote

50
Figure 13: state chart diagram for apply for candidate

51
Figure 14:state chart diagram for vote

52
Figure 15: state chart diagram

53
 CHAPTER FIVE
System Design
5.1. System Design Overview
Systems design is the process of defining the architecture, components, modules, interfaces, and
data for a system to satisfy specified requirements. System design could be seen as the
application of systems theory to the invention development.
5.2. Design Considerations
This part of the project deal with the system design of our system. In this system a related voters,
candidates and other information are found in the database. This means we do the transformation
of analysis models of the problem space into design models (solution space). So this part is just
problem solving or during this phase the overall structure and style of the system will be
discussed. And also we are focused on qualities and quantities of the system, describing the
subsystem and major policy decision like, access control, hardware and software map, data
storage and data management. Also in this phase all requirements what we are developed as
application domain are got a solution. It represents a model of final production details of
representation of the system components.

5.3. Design Goals

Design goals describe the qualities of the system that developers should optimize. Such goals are
normally derived from the non-functional requirements of the system.
The system changes the existing manual werabe University student union election system into
automated way and these also minimize resources needed to operate each operation. These goals
grouped in to the following categories.
Security: Unauthorized access to the system should be restricted. Hence, group level system
security will be implemented to prevent unauthorized personnel from accessing the system. There
are groups with different privilege levels are defined. Users created by the administrator belong
to a specific group and will be given a password and user name to access the system at the
privilege of his/her group.

54
Performance: To meet system performance:
Since the system is web based, the deliver response time of the system should be very
fast. It performs its activity that are relating to the vote accurately.
Use pup up message and tabs to minimize page reload which is take much time when
Reload the page many times for the specific functionality.
Usability: The system is easy to use for the users. the functionalities are also arranged in a
Module based on the similarities of their function that are used for users to use the system easily.
Availability: The system should be available for access at restriction day and time at election
set by SSD. And also, the interaction between the voters and the system is more than enough to
know about the union and the election process.
Error handling: This system allows preventing or eliminating of error by displaying the
message box or the system warns the users who make errors.
Storage requirement: The system stores all the data related with all the tasks performed into
the database.
User Interface: The interface of the system should be user friendly (easy to use), display error
message if it detects invalid input.
5.4. Design Trade-offs
When designing a web-based student union representation election system, there are several key
design trade-offs that need to be considered:
Security vs. Accessibility: One of the most critical trade-offs is between security and
accessibility. Implementing strong security measures, such as multi-factor authentication and
encryption, can help protect the integrity of the election process. However, these security
measures may also make the system more complex and less user-friendly for students trying to
participate in the election.
Scalability vs. Cost: Another trade-off is between scalability and cost. Designing a system that
can handle a large number of users and votes may require more resources and infrastructure,
which can increase the overall cost of the system. Balancing scalability with cost constraints is
important to ensure that the system can handle peak loads during election periods without
incurring excessive expenses.

55
User Experience vs. Security: The user experience of the election system is also an important
consideration. While implementing strict security measures can help protect the integrity of the
election, it may also create friction for users trying to cast their votes. Finding the right balance
between a seamless user experience and robust security measures is crucial for ensuring high
participation rates in the election.
Transparency vs. Anonymity: Designing a system that ensures both transparency and anonymity
in the election process is another trade-off to consider. Providing transparency in the election
results can help build trust among students, but it may also compromise the anonymity of
individual voters. Striking a balance between transparency and anonymity is important to
maintain the integrity of the election while protecting the privacy of voters.
5.5. Architecture of the System
System architecture is the conceptual model that defines the structure, behaviour, and more views
of a student union management system. An architecture description is a formal description and
representation of a student union management system, organized in a way that supports reasoning
about the structure of the system. System architecture can comprise system components, the
externally visible properties of those components, the relationships (the behaviour) between
them.

Figure 16: software architecture of the proposed system

56
 5.6. System Decomposition
Subsystem diagram shows the service it provides or it accepts from other subsystems, and the
coupling and the coherence between them. Subsystem decompositions help the system like:•
To reduce the complexity of the solution domain, we have decomposed the system into
simpler parts, called subsystems, which are made of a number of solution domain
classes.
In the case of complex subsystems, we recursively apply this principle and decompose a sub•
system into simpler subsystems.
Decomposition Results large systems in to a set of loosely dependent parts which make up
the system.
Large system is usually decomposed into sub system layer and partition. In partition the system
vertically divided into several implement of sub system that provided service on the same level of
the abstraction whereas, layers are a sub system that provided system service to higher. In this
student union election systems, we have the following subsystems, which extracted from the
functional requirement that already described in the previous document.
 Student registration sub system
 Voting subsystem
 Information exchange and approval subsystem
 Account management subsystem
 Exam and election Time management subsystem
 Report subsystem

57
 5.7. Hardware/Software mapping
In a web-based student union representative election system, the hardware and software mapping
would involve identifying the specific hardware components and software applications required
to successfully implement and operate the election system. Here is a general outline of the
hardware and software mapping for such a system:

Hardware:

1. Servers: Hardware servers are needed to host the web-based application that will facilitate the
election process. These servers should have sufficient processing power, memory, and storage
capacity to handle the expected traffic and data volume.
2. Network Infrastructure: Routers, switches, and other networking equipment are required to
ensure reliable connectivity between users accessing the election system and the servers hosting
the application.
3. Computers: Users, including students and election administrators, will need computers or
devices with web browsers to access the election system interface.
4. Printers: Printers may be needed for generating physical copies of election materials such as
ballots or reports.
5. Security Devices: Firewalls, intrusion detection systems, and other security devices are
essential to protect the election system from cyber threats and unauthorized access.
Software:
1. Web Application: A custom web-based application will need to be developed to manage the
election process. This application should include features for voter registration, candidate
nomination, voting, and result tabulation.
2. Database Management System: A database management system (e.g., MySQL, PostgreSQL) is
required to store and manage data related to voters, candidates, election results, etc.
3. Security Software: Encryption tools, secure socket layer (SSL) certificates, and other security
software should be implemented to protect sensitive data and ensure secure communication
between users and the election system.
4. Content Management System (CMS): A CMS may be used to manage and update the content
of the election system website.

58
5. Backup and Recovery Software: Regular backups of election data should be performed using
backup and recovery software to prevent data loss in case of system failures or cyber-attacks.

5.8. Persistent Data Management

Persistence modelling is the diagram that shows the relationship between the tables that
interrelated with each other. It also shows self-relation of the tables. It is only used for object•
oriented database modelling; but for relational database modelling we use Entity Relationship
modelling instead of Persistence to show the relation of tables with each other.

Figure 17: persistent diagram

59
 5.9. User Interface Design
User interface design is the design of computers, appliances, machines, mobile communication
devices, software applications, and websites with the focus on the user's experience and
interaction. The goal of user interface design is to make the user's interaction as simple and
efficient as possible, in terms of accomplishing user goals which is called user centred design.
Good user interface design facilitates finishing the task at hand without drawing unnecessary
attention to it. Graphic design may be utilized to support its usability. The design process must
balance technical functionality and visual elements (e.g., mental model) to create a system that is
not only operational but also usable and adaptable to changing user needs

60
 Home Page

Home Visi Missi LOGI Apply for View

Conta Feedb Help
Apply for
Notice View
ct on N vote candidate election
ack on result promotion

Admin Voter SSD Candidate Main register

Home Home Home

Home
Home
Add notice manage
Take backup Vote exam date
Take exam
Management See notification
Restore View election date
backup election
result View exam
Manage student result
apply date Send student data
View
Manage Candid
account Manage feedback View election
ate
request result

Prepare exam
View View candidate
View promotio
n Submit student
discipline record
Manage
candidate Send notification
request

View candidate
Manager user
result View voter

Figure 18: use interface design

61
 5.10. Object Design

5.10.1. Interface documentation guidelines

Interface documentation guidelines for a web-based student union representative election system
are essential for ensuring clarity, usability, and consistency in the design and functionality of the
system. Here's a discussion outlining some key points:

User Interface Design Principles Follow established principles of user interface design such as
simplicity, consistency, clarity, and responsiveness.

Accessibility Standards : Ensure that the interface complies with accessibility standards such as
Web Content Accessibility Guidelines (WCAG) to cater to users with disabilities

Responsive Design: Design the interface to be responsive across various devices and screen sizes
to accommodate users accessing the system from different devices like desktops, laptops, tablets,
and smartphones

Clear Navigation: Implement intuitive navigation that allows users to easily move between
different sections of the election system. Utilize established navigation patterns such as
hierarchical menus, breadcrumbs, or tabbed navigation.

Form Design and Validation: Design forms for tasks like candidate registration or voter
authentication with clear labels, appropriate input fields, and validation mechanisms.

Feedback and Error Handling: Provide meaningful feedback to users after actions like submitting
a vote or updating candidate information. Implement error handling mechanisms to guide users in
resolving input errors.
Documentation Consistency: Maintain consistency in terminology, layout, and styling across all
interface elements. Create a style guide or design system to document and enforce these
standards.

Security Considerations: Ensure that the interface follows best practices for security, such as
encryption for sensitive data transmission and authentication mechanisms to prevent
unauthorized access.

62
14. References

[1].https:// www.wru.edu.et
[ 2]. http://en.wikipedia.org/wiki/Component_diagram
[3]. Object-Oriented and Classical Software Engineering 8" Edition by Stephen R. Schoch
[4].http://www.visual-paradigm.corn/VPGallery/diagrams/Class.html December 28, 2016
[5]. E. Burke and W.Eeben. Practice and Theory of Automated Timetabling,Third International
Conference, Germany, Springer Private Limited, August 2000
[6] Smith, J. (2020). "Modernizing Student Union Elections: The Case for a Web-Based Voting
System." Journal of Higher Education Administration, 15(2), 45-62. [7]. Johnson, A. (2019).
"Feasibility Study of Implementing a Web-Based Student Union Election System at XYZ
University." International Journal of Information Technology Management, 7(1), 32-45.
[7].http://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-buildingblocks/
system-design-and-
[8]. https://www.computerhope.com.

63