WOLKITE UNIVERSITY

ONLINE APPLICATION, ADMMITIONAND REGISTRATION

DOCUMENTATION

2014 E.C
 CHAPTER ONE
INTRODUCTION

As we all know Wolkite University is a second generation university that has built an
enormous name for the past years. As a student we want to put our finger print on the
future success of the the university. As we try to look around there is no online
registration system for students and applicants can apply and register on. Everything
is done manually which made another incompatibility of losing files and valuable
informations. Our focus area is changing the existing platform that is done manually
to digital form which will ease the students,stuff and file related problems.

1.1. Background of the Organization

Founded in 2011 G.C. Wolkite University is a Public higher education university
located in Wolkite ..., SNNPR. The University awards degree in arts & humanities,
business & social science, language & cultural, medicine & health, engineering,
Science & Technology. Internationally Wolkite University ranked 11913 in the world.
It has ranked 4 in SNNPR. This higher education university admission process is
based on entrance examinations and students' past academic record and grades. It
provides admission to Men and Women (COED) and international applicants are
welcome to apply for admission.

Missions
The university as indicated in the proclamation No. 650/2009, has the following
missions.
 To produce graduates who are knowledge, attitudinal mature and practically
innovation,
 To supply relevant demand technology and knowledge that address national and
community level development problem to help make operations of the
government and non-government organizations efficient, effective and
competitive and,
 To provide training consulting services to the community and the government.
Vision

 To be one of the 10 universities in East Africa by 2035 G.C.

Core value of Wolkite University

 Excellence! All operations in the university be effective, efficient, innovation, and

nullifies wastage of resources including graduates from the university.
 Inclusiveness! The university cultivates diverse religion, gender, special interest, and
develop collaboration and shared vision.
 Truth or integration! The university in the university feels society responsible and every
single activity in the university in the university positively adds value to the society.
 Being a learning organization! Institutional development or learning and growth is a
continuous culture.
 Accountability! The university believes in taking full accountability for addressing the
university, or the association social costs.
 Academic freedom! The university believes of free and critical thought and enquiry,
diversity beliefs, as will as the open exchanges of ideas and knowledge.

1.2 Statement of the Problem

In Wolkite university there is no online platform where students can apply, administer
and register and because of this students and applicants face a big problem.
Which means they need to be physically present because of this applicants were
vulnerable for extra money to pay for related expenses and also for wolkite university
it is figure defacement because a big university like wolkite having no platform for
registration is not much expected. Another core problem is because the registration is
done manually the files are vulnerable for lost and physical damage. The bureaucracy
is very unsatisfactory which make the applicants suffer a lot by going and coming
from bureaus to bureaus. The priceless time wasted on unnecessary procedure.
1.3 Objectives of the Project
Our objective is To make students and applicants able to apply even register in the
university by being where they want to be and not pay any extra money related to
registration in the way also make it easy to learn in our university or make the process
of registration easy as much as possible.and also protect the files of students in more
organized and safe format.

1.3.1 General Objective

The general objective of this project is to develop Student application, Admission
Registration System for wolkite University.

1.3.2 Specific Objectives

 To design the student application, Admission Registration System for wolkite

University
 To automate the current Application, Admission Registration System used at
wolkite University.
 To test and validate the new system of student Application, Admission
Registration Management System for wolkite University.
 To replace the existing system completely with the developed system starting
from 2015 E.C.

1.4 Feasibility

1.4.1 Technical feasibility

Technical feasibility centers on the existing manual system of the test management
process and to what extent it can support the system. According to feasibility analysis
procedure the technical feasibility of the system is analyzed and the technical
requirements such as software facilities, procedure, inputs are identified. It is also one
of the important phases of the system development activities. It is technically feasible,
since the whole system is designed into the latest technologies like Node.Js and
MongoDB which are the most recent technologies to develop web-based systems and
design databases. The system offers greater levels of user friendliness combined with
greater processing speed. Therefore, the cost of maintenance can be reduced.
Since, processing speed is very high and the work is reduced in the maintenance point
of view that the project is technically feasible.

1.4.2 Operational Feasibility

It is Operational feasible, since the system is providing an attractive user interface to

the operator/end user, so they feel very easy to work onto it. Response to operator/end
user is very fast and very good. Since, as we mentioned above that it requires much
less amount of cost, it uses computer work so it is very fast to operate and it is very
easy for user to work on it.

1.4.3 Economical Feasibility

Economic analysis is most frequently used for evaluation of the effectiveness of the
system. It is the procedure to determine the benefit and saving that are expected from
a system and compare them with costs, decisions is made to design and implement the
system.

It is economically feasible, it will require only few operators to operate the system,
who is responsible for entering the data into the database via a user interface provided
to them, who can also able to show all the data in tabular form so to provide
information regarding the students who are either registered or unregistered.

1.5 Scope and Limitation of the Project

Our project will include all the procedure of the student that the student pass through
in order to be a valid student member in our university. After the advertisement stage
it will go from the entry level that that manually handled by the registrar, course
payment process which is connected to the finance up to the department where the
student is applied to. All those processes will pass through our system.

1.5.1 Scope of the Project

The project will have application form where students can apply for the department
they need from wherever they are and if they full fill the education of minister
retirements and the university standards that was already described in the
advertisement that the university posted on mass media platforms they will be
admitted by the admission stuff and accepted by the department they will go to the
next process of registration. And in every semester the system will retrieve student
data from the SIMS and cross check if the student is fulfil the minimum score
requirement and give the appropriate decision. In every payment stage the system
retrieve the data from the finance if the student payed the required amount of fee and
again cross check and validate.

1.5.2 Limitation of the Project

The limitations will be not on the system side because but we think that we are going
to face A problem from the user side because as we know the web site is new and
digitized system so it will be difficult to just move from manual system to
computerized form because our people take time to accept new things and most of
them have no access for this kind of digital system before.
The other limitation the project will face related with advertisement because the
university have passed using the manual system as there main application,admission
and registration process so it will face in advertisement sector .
And the next limitation the project will face is in training the former stuffs the new
system because they have no priors experience of registering applicant in digitized
format. Inappropriate variables will be expected beyond the researchers’ control such
as students honesty,personal biases, inadequate pieces of information, and
uncontrolled setting of the study. However, the we try our best to control what be
affordable.

1.6 Significance of the Project

The project will have so many significance from different sides. when we see from
the organization side or the stuff of admission and registration which use the system
in short they will relief from there busy and stress full manual work which consume
there time and make them bored in the process of checking every single details
information of applicants which is a lot tedious.here our project will come to solve
this massive problem by making it fully digitized. When we come to the financial
professionals who checks every single bank slip for all applicants on the way of doing
this they may make some mistake because there is a lot to take with in the
bureaucracy.
And the main thing to consider is they are always taking a lot of financial risk which
if they made mistake they will be the one to pay the lose so our problem will decrease
the problem of risk taking.
In the direction of students they will have many advantages by saving there time
money and give them there absolute comfort by making them can apply from where
ever they want.

1.6.1 Beneficiary of the Project

The main actors that will benefit from the project are applicants, stuffs and the
organization.

1.7 Methodology of the Project

1.7.1 Data Collection Tools/Techniques

We used Primary Data Collection so that to get detailed information and this helped
us to analyze how the current system is working at the university and this provided a
layout for the foundation of developing the new system for our university.
Questionnaires
Questionnaires were prepared by our advisors, and our group members. Those set of
questions were organized and given to the respondents for answering and after being
answered, we have obtained the simplified information that helped us get organize.

Interview
Interviews were held with students that are at registration process at the time. It was
one of our tools for deep understanding and adaptability in terms of questions and
answers suitable for obtaining data requirements. This method provided us with an
opportunity to acquire more information from students who were pass through the
system.

Observation
While applying this technique we studied the phenomenon observing what was taking
place at wolkite University. This helped us to identify what, who, where, when and
how it was taking place.
1.7.2 System Analysis and Design
The overall objective in the development of database technology has been to treat data
as an organizational resource and as an integrated whole. DBMS allow data to be
protected and organized separately from other resources. Database is an integrated
collection of data. The most significant form of data as seen by the programmers is
data as stored on the direct access storage devices. This is the difference between
logical and physical data.
Database files are the key source of information into the system. It is the process of
designing database files, which are the key source of information to the system. The
files should be properly designed and planned for collection, accumulation, editing
and retrieving the required information.
The organization of data in database aims to achieve three major objectives: -
 Data integration.
 Data integrity.
 Data independence.
The system stores the information relevant for processing in the MongoDB database.

During system analysis phase, we analyzed and then after designed and developed a
new system that was tested and implemented in order to fill for the gaps that were
prevailing.

1.7.3 System Development Model

The iterative process model is a software development life cycle (SDLC) approach in
which the initial development work is conducted based on initial requirements that are
clearly defined, and subsequent features are added to this base software product
through iterations until the final system is completed. This SDLC approach does not
aim to create a comprehensive specification plan. Instead, the iterative development
model is a method for breaking down any major software development project into
smaller chunks. It is specifically designed to start with the bare minimum
requirements and only construct a portion of the program iteratively. Post that, the
prototype is examined again for any extra requirements and then the rest of the
planning, requirement analysis, deployment, and maintenance are all conducted. This
helps in identifying risks associated with the requirements at an early stage and
mitigate them.

Phase of iterative model

1. Requirement and Planning Stage:
During this phase, the business requirements are collected, and an analyst determines
whether or not they will be met within the allocated budget. It is used to layout the
business needs in detail and the System information (hardware or software) are
gathered and evaluated for feasibility.
2. Design Stage:
In this phase, the project team gets the complete set of requirements to begin their
work in a particular direction. They use different figures like a data flow diagram,
class diagram, activity diagram, state transition diagram, etc. to get a clear
understanding of the software design and help them proceed with the development.
Developers come up with many potential solutions based on their analysis.
Additionally, the size and criticality of the project is also an important factor in
determining the level and complexity of design for the project.
3. Coding Stage:
The actual construction of the system begins at this point in the project. This stage
will be guided by the analysis and design resulted from the Design Stage. All of the
requirements, planning, and design plans are executed and coded. The developer will
implement the chosen design using predetermined coding and metrics standards.
During the code development, they must implement a unit test at each level. This
stage should aim to achieve the goal of developing fully functional, testable system
for that iteration. Depending on the project, the complexity of efforts and time spent
on this iteration will vary.
4. Testing Stage:
This step involves testing the current build iteration to a set of standards and norms to
see if it meets them. Performance testing, stress testing, security testing, requirements
testing, usability testing, multi-site testing, disaster recovery testing, and so on are all
examples of this type of testing. A developer or a tester has to ensure that fixing one
bug does not lead to emergence of additional bugs in the system. The tester can write
new test cases or reuse ones from earlier builds, but testing is a top priority because
any errors would affect the software’s specification thereby impacting the business.
We can also check in with the project stakeholders to run some tests and inquire about
any feedback they may have.
5. Evaluation Stage:
This is the last stage of the iterative model. After all the processes are complete, the
system constructed up to this point is thoroughly evaluated. The system is examined
by the development team, stakeholders, and other teams responsible for developing
the project to see if the outcomes satisfy their expectations. A new requirement plan is
produced and implemented as part of the next iteration cycle based on this.

Why iterative model:

 In an iterative paradigm, less effort is spent documenting and more time is
allocated to design.
 It is easily adjustable and flexible to the projects and client’s changing
requirements.
 In comparison to other process models, this paradigm is significantly less
expensive to change requirements as we work on developing the project
iteratively once the requirements are frozen.
 The end-user can swiftly provide input after each iteration, which can
subsequently be incorporated into the system thereby improving the
experience of the application.
 Early in the software development life cycle, some working functionality can
be produced and released to the end users...
 It is possible to arrange parallel development since the iterations occurs
simultaneously.
 Risks are recognized and resolved as early as possible thereby making each
iteration readily controllable.
1.7.4 Testing methodologies
It is necessary to test the methods and to make various practical preparations. Tests or
pilot studies allow us to identify potential problems in the proposed study or system.
Testing refers to the process of executing the developed System in order to ensure that
it conforms to the user requirements and that it is functioning correctly. The goal of
testing is to ensure the system’s reliability and conformity to the user requirements. It
is useful in examining the practicability, reliability, and suitability of the method or
system.

1.7.5 Development Tools and Technologies

1.7.5.1 Front-end Technologies:
 React is a declarative, efficient, and flexible JavaScript library for building user
interfaces. ReactJS is an open-source, component-based front-end library
responsible only for the view layer of the application. It is maintained by
Facebook.
1.7.5.2 Back-end Technologies
 Node.js (Node) is an open-source development platform for
executing JavaScript code server-side. Node is useful for developing applications
that require a persistent connection from the browser to the server and is often
used for real-time applications such as chat, news feeds and web push
notifications.

1.7.5.3 Deployment Environment

The system will be deployed under wolkite university ownership and be available
across the world without restriction.
1.8 Team Composition
Project Manager: The project manager plays the chief part in the project and is
responsible for its success and quality. His job is to make sure that the project
proceeds and completes within the specified time frame and the ascertained budget,
and accomplishing its goals at the same time. Project managers ensure that resources
are sufficient for the project and maintain relationships with contributors and
stakeholders.
Project Team Member: Project team members are mainly the people who work on
various phases of the project. They could be in-house staff or external consultants and
maybe working on a full-time or part-time basis. Their roles can differ according to
each project.

1.9 Document Organization

Chapter 1
As we already described above chapter one talks about the introductory part of the
documentation.
Chapter 2
In this chapter we will talk about description of the existing system with it’s pros and
cons.In chapter two we will talk about the introductory part of the existing
system,users of the existing system,major function of the existing system with forms
and others documents of the existing system and also the drawback of the existing
system and its business rule.
Chapter 3
In this chapter we will talk about the proposed system as a solution for the existing
system problems. In this chapter we will talk about the functional and nonfunctional
requirement and with in nonfunctional requirement we will talk about the user
interface and human factors ,hardware consideration,system issues, performance
consideration,error handling and validation,quality issue,backup and
recovery,physical environment,resource issue documentation.
Chapter 4
Here in this chapter we will discuss abut the system model of the project we will talk
about the use case model , the use case diagram,use case description,use case
scenario.and the other thing we will talk about in this chapter is the object
model ,class diagram,data dictionary and other thing we will talk about is the dynamic
model. In dynamic model we will see sequence diagram,activity diagram, state chart
diagram.
Chapter 5
When we come to chapter five we will see system design and issues like design goals
like its performance,dependability,maintenance and others.another things like curent
system architecture and the proposed system architecture in proposed system
architecture we will see sub system decomposition and description, hardware/software
mapping, detailed class diagram, access control and security and other things will be
the packages with algorithm design and user interface design.

Chapter 6
In this chapter we will mainly talk about implementation testing and subtitles like
implementation of database, class diagram, configuration of application server,
configuration of application security, implementation of user interface and at last we
will see testing.
Chapter 7
In the last chapter we will see conclusion and recommendation.
 CHAPTER TWO

DESCRIPTION OF THE EXISTING SYSTEM

2.1 Introduction of Existing System

First when the university is ready and want to receive students it will post an
advertisement on different social medias and it’s website. The posted advertisement
includes departments that are available to apply on, and cafeterias to apply, things an
applier have to have when s/he comes to apply and a deadline to apply on. So after the
advertisement is shown for the public for some specific days and applying day
reaches when applier reaches at the university first s/he have to pay 50/100 birr for an
application form though bank to the university account and after they pay the payment
they will take the bank slip to finance stuff to get or change their slip to the financial
slip. So the finance stuff workers will check their slip and give them the financial slip.
And they will take the slip they get from finances to main registrar and the main
registrar see their financial slip and give the an application form. And then the
applicant will fill the form and give the form with their academic information to the
admission stuffs. After the admission stuff check their application it will decline or
admit the applicant.
Here the applicant have to wait until the given deadline of applying is completed, so
after the deadline day is reached there will be an applicant minimum number wanted
by the university to give that department to the students, so according to that if the
wanted number of applicant is meet main registrar will post the qualified department
and students list under those departments on the advertisement bored and call them
form registration process with putting deadline for it , or if the wanted number is not
meet main registrar will give them their second choice of department(if they have) or
decline the department. And register will order the department to send slip according
to applicants number that are qualified.
Now the departments and students are selected and known so the qualified applicants
will first pay the needed payment that is posted by CEDP according to their
department. As the first payment they will pay their payment by bank and get checked
the bank slip by finances stuffs and get finances slip.
After they did this they will prepare 4 copy of the finances slip for( finances, registrar,
department and themself), and will submit to the 4 actors that I already mentioned.
When they submit to register the stuff will check and give them slip for what they for
means if they only pay for department department slip only or if they pay to
department and other packages(for summer students only) like dormitory and
cafeteria it will give slip for those too. When the student is freshman student it will
receive two course slips one to his/herself and the other for the department it
registered for from main registrar and s/he will submit it to the department register.
But after the registration day is completed if the registered number doesn’t meet
minimum number so that department needed the main registrar will give them their
second choice of department(if they have) to the registrars or decline the department
and return their course payment money through main finance stuff.
Finally if applicant are enough in number then advertisement will posted by the
university stating when do the class starts.

2.2 Users of Existing System

There are many different parts who use the existing system if we start from the
applicants they are the first who use the existing system to apply for courses. the
student responsibility are to full-fill the requirements and and to pay the tuition and
related expenses .
The other users are CEP with the responsibility of releasing advertisement by stating
what is needed from the students and other related information. after that people will
apply.and CEP will compare the number of student who applied for the course and
the number of capacity needed by the university If the number of students are enough
CEP will release notice to register with deadline and tell departments with the courses
to send for slips for the number of students applied.then again the students will
register by paying the money.here if the number of students registered is less than
minimum needed then CPE will decline the course that year and the students who
payed will be transferred to another department if they are willing otherwise the
money they paid will be returned. The other actor who will be using the system is
registrar who will register students if they full-fill the needed qualification.if the
number of students is what is needed then registrar will accept slip from departments
to register new students.
The others parts who will be using the system are finance who are using the system
currently as follows they accept receipt from bank given by the payer and they will
check for originality and the if it is original they will change the receipt to the
university receipt And last but not least are departments who will accept the
registered students from the registrar office. They also give slip when they are asked
by the CPE.

2.3 Major Functions of the Existing System

The existing system major functions are as follow the first is releasing advertising
with the needed information the people will come by seeing the advertisement and
they will apply. Then CPE will compare number of students applied and minimum
number of students ready to accept.if at least they are enough the students will pay the
needed money according to credit hour the money will be released set by CPE by
calculating with credit hour. and they will be registered then CPE will again compare
the number of students registered with the number needed.if enough continue with
course else the course will be declined. So we generalize it the major functions are
advertisement ,application,admission and registration.

2.4 Forms and Other Documents of the Existing Systems

2.5 Business rules
Faculty/Staff Business Rules: With Faculty/Staff business rules, you set rules for
faculty/staff IDs and duplicate records. Automatically generate faculty/staff IDs
starting with Mark this checkbox so Admissions Office automatically generates new
faculty/staff ID numbers when you add faculty/staff to the database. You also
designate the first number to use when creating faculty/staff ID numbers.
If you automatically generate IDs, designate the number of characters to use when
creating new faculty/staff ID numbers.
Prefix faculty/staff ID with You can enter a prefix of up to five characters to add to
each new faculty/staff ID. Prevent data entry to the faculty/staff ID field Mark this
checkbox to prevent the faculty/staff ID field from being edited on records. This
business rule prevents missing and duplicate IDs.
Individual Business Rules: With Individual business rules, you set rules for
individual IDs and duplicate records. Automatically generate individual IDs starting
with Mark this checkbox so Admissions Office automatically generates new
individual ID numbers when you add individuals to the database. You also designate
the first number to use when creating individual ID numbers. If you automatically
generate IDs, designate the number of characters to use when creating new individual
ID numbers.
In the Field Name column, you can select fields to use in the duplicate search.
In the Length column, enter the number of characters to check in each field during the
duplicate search. Automatically check for duplicate individuals. With this business
rule, the program automatically searches for duplicate individual records based on
duplicate individual criteria when you save a new individual record. In the
corresponding field, you can require the program to either disallow duplicate
individuals or warn the user if duplicate individuals are found.
Registrar Business Rules -- With Registrar business rules, you set rules for Registrar
Setup in Configuration. Display the GPA Cutoff Value column on the Translation
Table Mark this checkbox to display the Cutoff Value column for each GPA type in
the GPA view of a translation table.
Student Business Rules: With Student business rules, you set rules for student ages,
status date updates, and duplicate student records. Base student age on Select how the
program determines each student's age based on birth dates. You can select System
Date, Academic Year, or Specific Date. If you select Specific Date, a date
field appears for you to enter the date. If you select System Date, the program
calculates a precise age based on the current date. If you select Academic Year, the
program calculates age based on the first date of an academic year. For example, you
may use this setting for reporting on applicant ages for the next academic year.
If you select Specific Date, the program calculates age based on a date you enter.
For example, you may use this setting for checking applicant ages as of a certain date
for cutoff requirements. Update status date when updating current status Mark this
checkbox to automatically update the status date to the current date whenever you
change the status on a student record. Duplicate student criteria. In this grid, you can
select specific student record fields to use as criteria when searching for duplicate
records. The duplicate search is useful for preventing users from entering duplicate
student records. In the Field Name column, you can select fields to use in the
duplicate search. In the Length column, enter the number of characters to check in
each field during the duplicate search. Automatically check for duplicate students
With this business rule, the program automatically searches for duplicate student
records based on duplicate student criteria when you save a new student record. In the
corresponding field, you can require the program to either disallow
duplicate students or warn the user if duplicate students are found.

CHAPTER THRE
3.PROPOSED SYSTEM
3.1 Functional Requirements
On the first page it will have advertisement page for calling applicants for specific
filed of study that are provided by the university and necessary criteria to apply on.
Next after applicants see the application on different mass medias if they want to
apply they will come to this system and it will provide login page and after they login
they will land on a page that have application from which asks the applicant all the
necessary information and provides document uploading system to up-lode their
academic files background results and other documents like photo… etc… that are
required. After they fill the form if they are qualified by the system after checking
some primary requirements, the system will send their application to the register stuff,
or if they aren’t qualified by the system will tell them to try again with correcting
some information. And if they are qualified they will get payment bar to pay for for
the application they just fill on and the payment system provided by system is either
direct payment like yena pay or by uploading a bank slip and submit. Finally the
system will show the a bar that tell them to wait until application day completes
because if the university didn’t get enough applicant on that filed of study it will
decline their application.
Then after the application day completed if the university get enough numbers of
applicant on that specific field of study it will notify the applicants by dynamic
reporting system that is provided through their email or sms saying their application is
accepted and attache file which contain sated money for their specific filed of study,
or if their application isn’t accepted it will tell them their application is declined or
they are given their second choice because their first choice is declined.
So if they still want to register they will pay the required payment for that filed of
study courses through the same payment system that they pay the first application
payment and the system will send notification to finance stuff workers and if they
approve it by checking to the specific filed of study sated payment the system will
show a bar that it’s registration is accepted but to be fully registered s/he have to wait
until registration day completed because if the university didn’t get enough registrar
students it will decline the specific field of study and return it course money.
So, Finally after registration day completed if the university get enough number of
students on that specific filed of study it will notify the students saying that they are
fully registered and attache day of class starts and their academic slip with it, or if it
didn’t get enough number of student their money will be returned through financial
procedure that financial has.

3.2 Nonfunctional Requirements

The system will have user friendly user interface where the user will feel comfortable
using it
It will not be very colorful or boring it will be indeterminate for the better of the
user.the system also security system which it will have its own authentication and
error handling methods that Is efficient to protect the users data.the hardware
consideration in minimum because it is web based so it will work on any computer
with internet access.
3.2.1 User Interface and Human Factors
The university logo and the current basic design of registration system should be
displayed. The system should be attractive according to the university-level students.
The design and the color should make users feel comfortable when using the system
instead of flashing useless colors on the screen. The design should also reflect the
universities environment.
The overall style should be built up easily in order for users to use it easily and
efficiently. After accessing the system, the users should feel comfortable while
looking at it and browsing through it. The design should not be too colorful to
maintain a certain seriousness of the web design of the college but at the same time it
should not be too boring for the eye, so that it can appear pleasant to use.
The system should have an easily understandable design in order for users to use it. It
should provide the necessary information when the user commits possible errors. It
should indicate the several possibilities that the user has to go on in using the system.
The user will be allowed to undo any of the operation computed or, for irreversible
operation, will always be asked to double-check their choice in case they
misunderstood the option or clicked on a button by accident. The system will have
easy access to help center whenever the user needs any kind of assistance.

3.2.2 Hardware Consideration

The product is Web based therefore it will be used in any environment that allows
Web access.
For the system to successfully operate the registration system should be integrated
with other IT services and the internet portal.
3.2.3 Security Issues
Everyone (stakeholders and guests) can have access to the system and the catalogue.
Every student must have secure and private access to his/her data. The CPE and the
registrar can have access to every part of the system.
Data integrity should be assured by limiting access to the database and by appropriate
synchronization, and back-up functionalities.
The system will provide a protection of the database such as the one that the
university already provides. However, the system will have to increment this level of
protection because of the personal data made available on the system, and the larger
share of people that will be having access to it through the online registration. The
users’ privacy will be granted by the limited access that the log-in process is going to
give to the database. Also, the system does not grant direct access to the database
itself. Stakeholders who need to access the database will have to access it from a
source independent from the registration system.
The system will develop a security system that will reduce to the minimum the
possibility of corruption from systems and/or humans
3.2.4 Performance Consideration
The system is required a fair amount of speed especially while browsing through the
catalogue and presenting different possibilities for the schedule. The outcomes of the
product are not directly influenced by its speed, because all the operations are linked
to each other and one operation can not be computed before the one causing it.
When the system is disconnected or frozen due to over access at the same time, it
should save all the process of the users have made up to the point of abnormal
happenings. When the users log in with the same id, all the work should be provided.
The system should be able to manage all the information incoming from the database
and the catalogue.

3.2.5 Error Handling and Validation

The product will have its own validation technique where the user will be asked to
insert necessary information which used to check for his eligibility if the person is
qualified he will be allowed to access the system but if he is not then the system will
not allow the man to enter the system. with related to error handling the user will be
aware to take caution when inserting data and if he makes a mistake he will be able to
correct it.

3.2.6 Quality Issues

The reliability of the system is directly linked to the level of update of the documents
to which it is correlated, such as the catalogue or the students’ database.there for it
should be seen time after time for a defect.
The availability of the system is 24/7 to students who want to register with in the dead
line.
3.2.7 Backup and Recovery
As stated above the system should be updated with specific time to find any
incompatibility and to correct it in time.the system will have feature where the data
will be restored to the initiation of the update if any error occurred.
And additionally we will have additional database where the users data will be stored
and which have no any relation with the currently updating database so if any error
occurred we can get the prior data set with ease.
3.2.8 Physical Environment
The system will be deployed with in the university where it is the main place the
registration will take place so that the coordinators can see it.
3.2.9 Resource Issues
As far as now there is no constraint on the resource the system will work on the
same hierarchy as the manual system work.there the resources are enough to go with.
 3.2.10 Documentation
The level of documentation gathered from the offices that work on registration the
offices include CEP,Registration Directorate, the departments and also the college.the
development process is also documented in case it is needed for technical
maintenance.

2.3) System models

The system model is composed of three individual models: -
1) Functional model: represented by use case and Scenario
2) System object model: represented by classes and objects diagrams and
3) Dynamic model: represented by state chart and sequence diagram.

In this section we try to analyze the overall activity of the proposed system by
using use case description, use case diagram, sequences diagrams, activity
diagrams and class diagram scenarios.

2.3.1) Use cases and Actors

2.3.1.1) Use Cases
Essential use cases that the proposed system consists are:-
1) Advertisment
2) Login
3) Application form
4) View Applicants
5) Approval
6) Payment
7) Payment check
8) Registration
9) Registration Slip
10) Available course
11) Departement Placement

2.3.1.2) Actors
The proposed system consists of three major actors for the accomplishment of the
system.
These are:-
1) Students
2) Registrar
3) Department head
4) CEP
5) Finance

2.3.1.3) Use case and actor description

Login Use Case

Use case name Login

Use case identifier UC#1
Actor(s) Applicants, department,registrar,CEP,finance
Description Applicants, department,registrar,CEP,finance want to use
the webpage
Precondition Applicants, department,registrar,CEP,finance should
create account
Post condition Applicants, department,registrar,CEP,finance use the
webpage

Basic course of Actions

1. Applicants, department,registrar,CEP,finance want to use the site
2. They have an account
3. They enter their user name, password and security key
4. Press login button
5. The entered fields are correct
6. They logged into the site
7. Use case ends

Alternate of courses of Action

Alternative course A: 2) If they have no an account
2.1) click create account button
2.2) fill all fields
2.3) get your security key
2.4) go to step 3
Information Registration Use Case
Use case name Information Registration
Use case identifier UC#2
Actor(s) Applicants
Description Applicants fill forms
Precondition Applicants apply.
Post condition Applicants can register.

Basic course of Actions

1. Students want to fill application form
2. They enter their ID No and security key
3. They click show form button
4. The entered values are correct
5. Application form will be displayed
6. Applicants fill the application form
7. All application form fields are filled correctly
8. Filling application form is success
9. Use case ends

Alternate of courses of Action

Alternative course A: 4) If entered values are not correct
4.1) error message will be displayed
4.2) go to step 2
Alternative course B: 7) If all application form fields are not filled correctly
7.1) fill all fields error message will be displayed
7.2) go to step 6
View Applicants Use Case
Use case name View Applicants
Use case identifier UC#3
Actor(s) CEP and Registrar
Description CEP and Registration office are able to see Applicants
Precondition The Applicants must have applied.
Post condition Compare number of Applicants and needed number of
applicants

Basic course of Actions

1. Applicants apply for registration.

2. The applicants will pay application fee.
3. Applicants fill the application form.

Approval Use Case

Use case name Approval

Use case identifier UC#4
Actor(s) Registrar, department
Description Registrar,Department approve applicants
Precondition The Applicants will enter necessary information
Post condition Applicants will be confirmed
Basic course of Actions

1. Students will see the login page

2. Students will apply.
3. Registrar and department will judge if applicants can take the courses
available
Alternate of courses of Action
Alternative course A: 3) If the students do not fill each fields correctly
3.1) Message (fill each field with correct data) will be
displayed.
 3.2) if not qualified will not let them to register
3.3) there registration process will terminate

Payment Use Case

Use case name Payment

Use case identifier UC#5
Actor(s) Applicant,finance
Description Applicant pay for course
Precondition The students should of applied successfully and accepted
Post condition Applicants will be allowed to take courses
Basic course of Actions

1.Students login to the page

2.Students want to be registered for courses
3.Fill all required field on the page
4.Students will apply.
5.Applicants will pay for the courses the want to learn

Alternate of courses of Action

Alternative course A: 3) If the students do not fill each fields correctly
3.1) Message (fill each field with correct data) will be
displayed.
Alternative course A: 4) If students do not pay
4.1) Message will be announced to pay
4.3) if not applied will not let them to register

Approve Payment Use Case

Use case name Approve Payment

Use case identifier UC#6
Actor(s) Finance
Description Finance will check the the originality of the receipt.
Precondition The Applicants should pay
Post condition Applicants will be registered
Basic course of Actions

1.Students will see the login page.

2.Student will register for for course
3.Applicant will pay and send the screen shot of the receipt.
4.Finance check eligibility of the receipt
Alternate of courses of Action
Alternative course A: 3) if the student do not pay they will not be registered

Registration Use Case

Use case name Registration

Use case identifier UC#2
Actor(s) Applicants
Description Applicants register for course
Precondition The Applicants have an account and security key to
login
Post condition Applicants registration is success full.
Basic course of Actions

4. Students want to be registered for courses

5. Students login to the page
6. Fill all required field on the page
7. Students qualification mark is above or equal to the passing mark
8. Registration is successful
9. Students get registration message
10. Use case ends

Alternate of courses of Action

Alternative course A: 3) If the students do not fill each fields correctly
3.1) Message (fill each field with correct data) will be
displayed.
 3.2) Use case loops to itself
Alternative course B: 4) If students qualification mark is less than passing mark
Alternative course C: 5) if Applicant did not pay
5.1) the applicant will not be allowed to go to registration
phase
4.1) Use case ends.

Registration slip Use Case

Use case name Registration slip
Use case identifier UC#8
Actor(s) Applicants
Description The registered applicants want to take registration slip
Precondition The student must be registered
Post condition Both of them get and print registration slip.
Basic course of Actions

1. Applicants want to get registration slip

2. Applicants registration is success
3. Print registration slip tag will appear
4. Students click on print button
5. Registration slip is printed
6. Use case ends

Alternate of courses of Action

Alternative course A: 3) If the students registration is not success
3.1) use case ends

Available course Use Case

Use case name Available course
Use case identifier UC#9
Actor(s) The applicant,department
Description The student will have brief description of the courses.
Precondition The applicant should apply
Post condition The student will register.
Basic course of Actions

7. The applicant want to know available courses

8. Successful application
9. Brief description of the courses

Alternate of courses of Action

Alternative course A: 3) if application was not successful registration ends

Notify Use Case

Use case name Notify
Use case identifier UC#11
Actor(s) The Registrar,Applicant
Description The student will get Notification.
Precondition The applicant should register first
Post condition The student will get notification.
Basic course of Actions

10. The applicant want to know if he is registered.

11. Successful registration
12. The applicant will get notification
Alternate of courses of Action
Alternative course A: 3) if application was not successful registration ends

Document Uploading Use Case

Use case name Document Uploading
Use case identifier UC#12
Actor(s) Applicant
Description The Applicant can upload files
Precondition The applicant should fill the form first
Post condition The student will upload needed files.
Basic course of Actions

13. The applicant fill the form

14. The applicant is needed to provide original data.
Alternate of courses of Action
Alternative course A: 3) if application did not fill the form.
The use case will end

Downloading Resume Use Case

Use case name Downloading Resume
Use case identifier UC#13
Actor(s) Registrar,Applicant
Description The Applicant and Registrar can print Resume
Precondition The applicant should Apply
Post condition The applicant will print the resume.
Basic course of Actions

15. The applicant fill the form

16. The applicant can download the resume.
Alternate of courses of Action
Alternative course A: 3) if application did not fill the form.
4) If the application was not successful
4.1) the student will not upload.
 CHAPTER Five
5. SYSTEM DESIGN DOCUMENT (SDD)
5.1 Purpose of the System
Registration office is among offices of Wolkite University that perform student
registration process for around 15,000 students.
The registration still uses manual registration system that is difficult to perform the
activity in efficient manner, consumes resources and time of both the registrars and
students.
The purpose of this new system (Online Application, admission and Registration
System) will reengineer the current system, bringing new technology for the office so
that students of the campus can be registered being online without contacting the
registrar. These minimize loss of resource such as transport and time.
5.2 Design Goals
The design goals represent the desired qualities of Student Online Registration
System and provide a consistent set of criteria that must be considered when make
design decisions. Based on the non functional requirements the following design goals
will have to be achieved in order to qualify the system as successful.
1. Dependability criteria:
Robustness: The system has to be robust enough to manage any invalid
input from the users.
Reliability: The system has to perform all operations of the registrar
with no errors.
Security: This is one of the most important nonfunctional requirements
for securing all information and data of the office.
2. Cost Criteria:
Deployment cost: The system has to be easy enough to have a cheap
training cost.
3. Maintenance Criteria:
Extensibility: the system must support that new functionalities can be
added.
Modifiability: The system has to be highly modifiable to maintain.
Readability: The system has to be readable to assure its modifiability.
 Traceability of Requirements: the code should be easy to be mapped to
specific requirements.

4. End User Criteria:

Utility: The system has been conceived specifically to support the
students and employers.
Usability: The system will be designed in a user friendly fashion, both
for students and employers of registrar.
Proposed System

5.3 System Design Model

5.3.1) Subsystem Decomposition
During the subsystem decomposition we divide the system into smaller subsystem.
Each subsystem is strongly coherence and loosely coupled.
The system will be decomposed based on the use case and different actors defined in
the system. The decomposition shows the existence of the following subsystems.
User management subsystem
Account management subsystem.
Transaction management subsystem.
Storage subsystem.
Database subsystem.
The storage subsystem will encapsulate the database, providing a common interface
to the other three high level subsystems.
The following figure shows relationship between subsystem decomposition.

5.3.2) Hardware /Software Mapping

Online Application, admission and Registration System will be web-based so that
students and employers access through the internet. All functionality will be
performed in the main host and will be accessed through Wolkite University website
(www.Wolkite.edu.et) by all users.
The system will run on windows and other operating system. The programming
language used to develop this product will be Mern Stack and we have used Mongodb
as the database management system.
The following diagram illustrates software and hardware mapping of the system.
This figure shows relationships between subsystem decomposition with class.

5.3.3) Persistent Data Management

The followings are persistent data objects based on the requirement analysis
document.
Person: this is information about all the system users. It can be system
administrator and user.
Account: It is information about the registration accounts. It includes the
account holder’s information.
 Transaction: Detail information about database transaction when different
students registered at the same time in the same table
This persistent information will be stored in a relational database management
subsystem. We have selected Mongodb due to its versatility, high performance and
integration with the other products that constitute the new platform.

5.3.4 Access Control

The access control for the system is implemented through the capabilities list. This
representation comes up to be more compact and efficient for the system. A capability
associates a class, operation paired with an actor. A capability allows an actor access
to an object of the class. Denying access is another word for denying capability.
Registrar Capability List:
Class Operation
createAccount(),
Select Menu updateLogin(),
Login()
Create Login Menu CreateStudentLogin(),
CreateDepartmenttLogin()
Create Student Login Form Create(), Update(), Login()
Create Department Login Form Create(), Update(), Login()
Create Login Report Show(),Print(),Exit()

The above table indicates that Registrar can create account for departments, students
and give them access control.
Students Capability List:
Class Operation
createAccount(),
Select Menu updateLogin(),
Login(),
fillForm(),
Pay()
Create Login Report Show(),Print(),Exit()

The above table indicates that Students can create account with the help of registrar,
edit their account and print information

Department Capability List:

Class Operation
createAccount(),
Select Menu updateLogin(),
Login(),
printSlip(),
Create Login Report Show(),Print(),Exit()
The above table indicates that Head of Department can create account with the help of
registrar, edit their account and print information
Finance Capability List:
Class Operation
createAccount(),
Select Menu updateLogin(),
Login(),
approvePayment()
Create Login Report Show(),Print(),Exit()

Admin Capability List:

Class Operation
createAccount(),
Select Menu updateLogin(),
Delete(),
Manage(),
Login(),
approvePayment()
Create Login Report Show(),Print(),Exit()

The above table indicates that Admin can create account edit their account and print
information of theres and also others.

CDEP Capability List:

Class Operation
createAccount(),
Select Menu updateLogin(),
approveDepartment(),
Login(),
approvePayment()
Create Login Report Show(),Print(),Exit()

The above table indicates that CDEP can create account edit their account, approve
departments and print information of theres and also others.

5.4 Detailed Design

Introduction
Wolkite University Online Application,Admission and Registration is a system to be
developed to change the manual system into automated system. The system will be
uploaded on a central server to be accessed by multiple users. It will have user-
friendly interfaces to interact with the users easily. User will type their user name and
password on the login form and the system will check the validity of the user in the
database. If a match is found the user will be allowed to access the system with the
privilege level assigned to him/her. If a match is not found in the database the system
will display a message telling the user to re-enter the user name and password or else
service will be denied

5.4.1) Object Design Model

1. Performance criteria
Response time. Refers to the time delay the user wait for accessing the
page. It is mainly depend on the connection type of our internet.
Throughput. Refers to the number of tasks/operations that can be done at
a time.
Memory: This is the required memory size, so as to run the application
properly. The proposed system will need minimum of 512MB of Memory
for client machines and 1 GB for server. And internet connection is the
first step of processing. Offline users don’t have the opportunity to use the
site.

2. Durability versus platform dependence

This software product is designed to platform independent software in order to run
meeting the following hardware specifications.

3. Dependability criteria
Availability. It refers to the degree to which the system is found doing
normal task. The system works as long as connection is available.

Fault Tolerance- ability to operate under erroneous conditions. The

system back up data to avoid loss of data when system crash or
damage.

5.4.2 Detailed Class Diagram