All Chapters

TABLE OF CONTENTS
EXECUTIVE SUMMARY-------------------------------------------------------------------------------------- I
ACKNOWLEDGMENT---------------------------------------------------------------------------------------- II
LIST OF ACRONYMS---------------------------------------------------------------------------------------- III
1 INTRODUCTION--------------------------------------------------------------------------------------- 1
1.1 BACKGROUND OF THE PROJECT------------------------------------------------------------------------------------------------2
1.2 STUDY OF EXISTING SYSTEM----------------------------------------------------------------------------------------------------3
1.3 STATEMENT OF THE PROBLEM--------------------------------------------------------------------------------------------------4
1.4 SIGNIFICANCE OF THE PROJECT-------------------------------------------------------------------------------------------------5
1.5 OBJECTIVES----------------------------------------------------------------------------------------------------------------------6
1.5.1 General Objectives----------------------------------------------------------------------------------------------------- 6
1.5.2 Specific Objectives----------------------------------------------------------------------------------------------------- 6
1.6 SCOPE AND LIMITATIONS OF THE PROJECT------------------------------------------------------------------------------------7
1.6.1 Scope of the Project--------------------------------------------------------------------------------------------------- 7
1.6.2 Limitations of the Project-------------------------------------------------------------------------------------------- 7
1.7 METHODOLOGY AND TOOLS----------------------------------------------------------------------------------------------------8
1.7.1 Data Collection Methodology--------------------------------------------------------------------------------------- 8
1.7.2 System Analysis and Design Methodology-----------------------------------------------------------------------9
1.7.3 System Development Tools----------------------------------------------------------------------------------------- 10
1.7.3.1 Hardware Requirement--------------------------------------------------------------------------------------------------- 10
1.7.3.2 Software Requirement---------------------------------------------------------------------------------------------------- 10
1.8 PROJECT MANAGEMENT TECHNIQUE----------------------------------------------------------------------------------------11
1.8.1 Project Schedule------------------------------------------------------------------------------------------------------ 11
1.8.2 Project Budget-------------------------------------------------------------------------------------------------------- 12
1.8.3 Project Breakdown--------------------------------------------------------------------------------------------------- 13
1.8.4 Risk Analysis, Identification, Mitigation and Monitoring----------------------------------------------------14
1.8.4.1 Risk----------------------------------------------------------------------------------------------------------------------------- 14
1.8.4.2 Mitigation-------------------------------------------------------------------------------------------------------------------- 15
1.8.4.3 Monitoring------------------------------------------------------------------------------------------------------------------- 15
2 REQUIREMENTAL SPECIFICATIONS---------------------------------------------------------16
2.1 FUNCTIONAL REQUIREMENT--------------------------------------------------------------------------------------------------16
2.2 NON-FUNCTIONAL REQUIREMENTS------------------------------------------------------------------------------------------17
2.3 FEASIBILITY ANALYSIS----------------------------------------------------------------------------------------------------------18
2.3.1 Economic Feasibility------------------------------------------------------------------------------------------------- 18
2.3.2 Technical Feasibility-------------------------------------------------------------------------------------------------- 19
2.3.3 Political Feasibility--------------------------------------------------------------------------------------------------- 19
2.3.4 Operational Feasibility---------------------------------------------------------------------------------------------- 19
3 SYSTEM ANALYSIS--------------------------------------------------------------------------------- 20
3.1 ACTOR AND USE CASE IDENTIFICATION--------------------------------------------------------------------------------------20
3.2 USE CASE DIAGRAM-----------------------------------------------------------------------------------------------------------21
3.3 USE CASE DESCRIPTION-------------------------------------------------------------------------------------------------------23
3.4 SEQUENCE DIAGRAM----------------------------------------------------------------------------------------------------------30
3.5 COLLABORATION DIAGRAM---------------------------------------------------------------------------------------------------38
3.6 ACTIVITY DIAGRAM------------------------------------------------------------------------------------------------------------41
3.7 STATE CHART DIAGRAM-------------------------------------------------------------------------------------------------------49
Graduates Credential Verification Systems for MWU Page

4 SYSTEM DESIGN------------------------------------------------------------------------------------- 53
4.1 CLASS DIAGRAM---------------------------------------------------------------------------------------------------------------54
4.2 DEPLOYMENTS DIAGRAM-----------------------------------------------------------------------------------------------------55
4.3 COMPONENTS DIAGRAM------------------------------------------------------------------------------------------------------57
4.4 USER INTERFACE PROTOTYPE-------------------------------------------------------------------------------------------------58
CONCLUSIONS------------------------------------------------------------------------------------------------- 60
REFERENCES-------------------------------------------------------------------------------------------------- 61

LIST OF TABLES
Tables Name Page
TABLE 1:1 HARDWARE REQUIREMENTS----------------------------------------------------------------------------------------------------10

TABLE 1:2 SOFTWARE REQUIREMENTS-----------------------------------------------------------------------------------------------------10
TABLE 1:3 PROJECT BUDGET----------------------------------------------------------------------------------------------------------------12
TABLE 1:4 TABLE OF PROJECT BREAKDOWN------------------------------------------------------------------------------------------------13
TABLE 2:1 ECONOMIC FEASIBILITY----------------------------------------------------------------------------------------------------------18
TABLE 3:1 ACTOR AND USE CASE IDENTIFICATION-----------------------------------------------------------------------------------------20
TABLE 3:2 USE CASE REPRESENTATIONS----------------------------------------------------------------------------------------------------21
TABLE 3:3 USE CASE DESCRIPTIONS--------------------------------------------------------------------------------------------------------23
TABLE 3:4 USE CASE DESCRIPTIONS FOR LOGIN--------------------------------------------------------------------------------------------24
TABLE 3:5 USE CASE DESCRIPTION FOR VERIFY CERTIFICATES-----------------------------------------------------------------------------25
TABLE 3:6 USE CASE DESCRIPTIONS FOR INSERT, UPDATE SEARCH, AND DELETE GRADUATES INFORMATION--------------------------26
TABLE 3:7 USE CASE DESCRIPTION FOR ACCEPT PAYMENT--------------------------------------------------------------------------------27
TABLE 3:8 USE CASE DESCRIPTION FOR APPROVE VERIFICATION SERVICE REQUEST------------------------------------------------------28
TABLE 3:9 USE CASE DESCRIPTIONS FOR CREATE OR MANAGE ACCOUNT----------------------------------------------------------------29
TABLE 3:10 SHAPES OF SEQUENCE DIAGRAM----------------------------------------------------------------------------------------------30
TABLE 3:11 REPRESENTATION OF ACTIVITY DIAGRAM-------------------------------------------------------------------------------------41

LIST OF FIGURES
Figures Name Page
FIGURE 1:1 WATERFALL MODEL OF SYSTEM DESIGN.........................................................................................................9

FIGURE 1:2 GANTT CHART.........................................................................................................................................11
FIGURE 3:1 USE CASE DIAGRAM.................................................................................................................................22
FIGURE 3:2 SEQUENCE DIAGRAM FOR LOGIN.................................................................................................................31
FIGURE 3:3 SEQUENCE DIAGRAM FOR REQUESTING ACADEMIC SERVICE..............................................................................32
FIGURE 3:4 SEQUENCE DIAGRAM FOR ACCEPT PAYMENT FOR SERVICE................................................................................33
FIGURE 3:5 SEQUENCE DIAGRAM FOR APPROVING SERVICES (FOR CREDENTIALS FROM GRADUATES)........................................34
FIGURE 3:6 SEQUENCE DIAGRAM FOR VERIFY CERTIFICATES..............................................................................................35
FIGURE 3:7 SEQUENCE DIAGRAM FOR SEARCHING GRADUATES INFORMATION FROM THE DATABASE........................................36
FIGURE 3:8 SEQUENCE DIAGRAM FOR CREATE ACCOUNT.................................................................................................37
FIGURE 3:9 COLLABORATION DIAGRAM FOR LOGIN.........................................................................................................38
FIGURE 3:10 COLLABORATION DIAGRAM FOR REQUESTING SERVICE...................................................................................39
FIGURE 3:11 COLLABORATION DIAGRAM FOR VERIFY CERTIFICATES....................................................................................40
FIGURE 3:12 ACTIVITY DIAGRAM FOR LOGIN.................................................................................................................42
FIGURE 3:13 ACTIVITY DIAGRAM FOR CERTIFICATE VERIFICATION REQUEST..........................................................................43
FIGURE 3:14 ACTIVITY DIAGRAM FOR ACCEPT PAYMENT..................................................................................................44
FIGURE 3:15 ACTIVITY DIAGRAM FOR APPROVE SERVICE BY THE REGISTRAR DIRECTOR...........................................................45
FIGURE 3:16 ACTIVITY DIAGRAM FOR VERIFY................................................................................................................46
FIGURE 3:17 ACTIVITY DIAGRAM FOR SEARCH, UPDATE, DELETE AND INSERT (MANAGE GRADUATE INFORMATION).....................47
FIGURE 3:18 ACTIVITY DIAGRAM FOR CREATE OR MANAGE ACCOUNT................................................................................48
FIGURE 3:19 STATE CHART DIAGRAM FOR LOGIN...........................................................................................................49
FIGURE 3:20 STATE CHART DIAGRAM FOR CERTIFICATE VERIFICATION................................................................................50
FIGURE 3:21 STATE CHART DIAGRAM FOR REQUEST SERVICE............................................................................................51
FIGURE 3:22 STATE CHART DIAGRAM FOR ADMIN PAGE..................................................................................................52
FIGURE 4:1 CLASS DIAGRAM......................................................................................................................................54
FIGURE 4:2 DEPLOYMENT DIAGRAM............................................................................................................................55
FIGURE 4:3 COMPONENT DIAGRAM............................................................................................................................57
FIGURE 4:4 USER INTERFACE PROTOTYPES (DESIGN).......................................................................................................58
FIGURE 4:5 USER INTERFACE PROTOTYPE (SNAPSHOT)....................................................................................................59

EXECUTIVE SUMMARY
Forgery has long crept into our educational system and counterfeit certificate(s) and
document(s) have upper hand in various certificate and degrees awarding institution. Invalid
studentship has become greater than valid studentship. The need for student verification
system has become necessary to check mate and expunge invalid studentship, invalid
document and invalid certificate yielding for the authenticity of certificate and documents.
This project titled “Graduates Credentials Verification System for Madda Walabu
University”. The proposed model is concerned with verifying certificates (graduate,
postgraduate) issued from MWU and processing several academic requests from the
graduated students in the future. Graduates Credentials Verification System for Madda
Walabu University provides a comfortable communication among MWU and outside
organization(s) as nation’s source for accurate degree data. Moreover, it will be a web based
system where the users will be provided with comfortable interfaces to interact with MWU
for their immediate requirements in a trustworthy manner from anywhere. The system will
have a great significance on the MWU as well as Ministry of Education in the future. This is
an attempt from Ethiopians for the Ethiopians to obliterate the counterfeit from the
educational systems.

ACKNOWLEDGMENT
First of all we would like to give a great thanks to the Almighty God who helped us to
success well. We take this opportunity to express our sincere thanks to our Advisor Mr
Amanuel Assefa for the best guidance and support through his suggestions and ideas
throughout our project and correcting various documents error of project team with attention
and care. Finally, we have special thanks to the workers of Madda Walabu University
registrar office who helped us in providing the necessary information and material such as
working manuals for preparing this document and, for our classmate students for their great
help and keeping us some suggestions based on the projects and others.

LIST OF ACRONYMS
CD Compact Disc
CGPA Cumulative Grade Point Average
ERD Entity Relationship Diagram
EC Ethiopian Calendar
GB Giga Bytes
GUI Graphical User Interface
GVCS Graduates Credential Verification Systems
HTML Hypertext Mark-up Language
ID Identification Number
IE Internet Explorer
IIS Internet Information Service
IP Internet Protocol
MS Microsoft
MWU Madda Walabu University
MWUGCVS Madda Walabu University Graduates Credential Verification Systems
MySQL Structured Query Language
PHP Hypertext Pre-processor
RAM Random Access Memory
TCP Transmission Control Protocol
UC Use Case
UI User Interface
UML Unified Modelling Language
WAMP Windows Apache MySQL PHP

1 INTRODUCTION
A verification system as in this project is an application program used to verify that someone
or something rightly and legally belongs to a collection or an organization. There are
different verification system, especially address verification system and card verification
system to mention but a few. Credentials verification system is used to know whether or not
the certificate provided is legal and rightly issued for the student. In this context, it is also
used to verify that a student belongs to an institution and to confirm that he or she is properly
registered in a particular department running any of the institutions program and checking
whether the student Credentials is correct even if their name is registered and certificate is
given for them. This Credentials verification system, is an electronic and computerized means
of verifying someone’s claim of studentship or validating degree certificate by an institution
using an output clearly showing the truth or false of his or her claim.

1.1 Background of the Project
Madda Walabu University is one of the higher educational institution, in fact, among the
recently founded (1999 E.C) institutions of public higher education of the country. However
despite its being new the university can be categorized as the rapidly changing institution in
terms of student admission, expansion of programs and campuses. Currently the university is
running over 42 programmes at B.A, B.Sc., and M.Sc...It has 10 schools, 1 institute and 1
college[CITATION Placeholder1 \l 2057 ].
Over the past decades, students identification and verification has been a major problem in
large institutions as documents, certificate and studentship can be forged at a great rate and
easy way, using the computer negatively. Forgers fail to know that in this fast moving world,
the computer has equally served as an aid to decision making, verification and authentication.
This is because of computers efficiency in terms of speed, accuracy, reliability, cost and
security among others. In recent years, awareness has existed and created in people as it
concerned the use of computer in verifying, authenticating and security activities either
through web-based (internet) or window-based. The value of every degree is the reputation of
the institution and the students produced, hence, the greatest obstacle to any academic
institution which is dishonesty and forgery has to be checked with verification and
authentication systems and processes. Certificate verification is mandatory for most of the
reputed companies or organizations in order to reduce the risks related to it. Most of the
universities as well as educational providers comes up with computerized verification
systems and also support electronic verifications. But Madda Walabu University still now has
no such verification system that can help essential for the graduated students when they are
hiring or hired in any organization. Also enrolment verification is designed to fulfil the
verification requirements of companies that offer products or services requiring proof of a
student's enrolment status. For accessing several academic documents graduated students
spends much time and cost and loose several good career opportunities in their life.

1.2 Study of Existing System
Now a day’s educational credential or certificate needs a verification or validation system.
But most of the organizations or companies depend on the manual system provided by the
educational institutions or Universities in order to verify their employee’s credentials. In
Madda Walabu University also there is no computerized verification or validation system that
helps to verify the credentials of their graduates. Any organization that need to hire MWU
graduates they verify it manually by checking the university logo, stamps in the credentials of
MWU and by sending postal for an approval letter from MWU or simply ignore verifications.
Also MWU gives academic credential verification request service for the candidates
manually that means the user must come and request to the registrar by using academic
request form which is a time taking process. It also has to depend on the concerned officer’s
time and availability. Students are offered concessions in different offices throughout the
country. With things going online and education and careers depending a great deal on it, we
will have to rise up to the changing times.

1.3 Statement of the Problem
At present Madda Walabu University is not having any computerized system to deal with
degree verification for bachelors as well as post graduate degree holders from here. Only
thing is the employer or whoever concerned needs to contact the office of registrar or
academic record office for such purposes can contact the registrar and then get the student
Credentials. This is one of the great impacts on Madda Walabu University and also the
country.
 Difficulty of searching the graduated students file.
 Time consuming and costive.
 Vulnerable to different factors such as fraud certificate and corruption.
 Lack of security in existing system.
 Tedious and less speed.
 Illegal or faulty modification of credentials.
 Fault certificate made by Madda Walabu University name.
 Increased illegal employee in the country.
 Declined legal credentials values
 Embarrassment and negative impact to the organization's reputation.

1.4 Significance of the Project
The benefits of the project are listed below:
 Cost and time reduction.
 Minimize faulty certificate.
 Avoid modification made by students on their credentials.
 Increased the speed of access or faster credential verifications.
 Reduction in material usage.
 Increased accuracy and availability.
 Increased quality of education throughout the country.
 Minimize corruption.
 Greater convenience.
 Allows Accessing database easily.
 Improved fraud detection.
 To make timely and well-informed hiring, promotion and compensation decisions in
an organization.
 Avoiding data loss because of improper data storage.
 Reduce manpower.

1.5 Objectives
1.5.1 General Objectives
The general objective of this project is to design, develop and to test ‘GCVSMWU” that
provides instant online verifications of university degrees and post graduates certificates,
immediate, secure and affordable online credentials verifications, various timely and well
informed service for different verification requests from organizations and management of
the graduate student’s information are centralized.
1.5.2 Specific Objectives
To achieve the above mentioned general objective, the project addressed the following
specific objectives. The system provides the following:
 Prepare user friendly website where specific action for registrar, administrator and
external users such as organizations are defined.
 Store and manage graduated student’s information.
 Give proper administration features like:
 User management and authentication.
 Having downloaded or send features in order to download or e-mail the verified
information of the candidate or degree and post graduated professional certificate(s)
in the form of mark sheet.
 Online application for various service required by the organization.
 Design and implement a database for proper implementation of the system.
 Search graduated students file.

1.6 Scope and Limitations of the Project
1.6.1 Scope of the Project
The scope of this project focus on online Graduated credentials verification system for MWU
and authentication of documents only for bachelor’s degree and post graduate degree. Thus
graduates were must be graduated from MWU and also the system is available only for
MWU.
1.6.2 Limitations of the Project
 Non-graduating students or any person are not entered to the system.
 Payment modes for academic credentials verifications requests are only e-mail
message transfer. Internet banking is not made available in our country.
 It may vulnerable to threats.
 If there is no power and internet connection the system is not available.
 The system available for only Madda Walabu University.

1.7 Methodology and Tools
1.7.1 Data Collection Methodology
Data collection is one of the important tasks in determining and analysing the existing
system. The data that we need to develop the new system are obtained from system users,
forms and documents in the Madda Walabu University main registrar.
To gather data from the different users and manager of the existing system project team used
the following techniques.
 Interview: Different users of the existing system along with manager were involved
to have an understanding about how the system works, what are its different features,
factors, and any disadvantage as well as advantages so we obtain detail information
from them.
 Direct Observation: We observed various online verification systems and academic
request service providers on the internet. We will have also observed the existing
academic credentials request system to know how the process is going and to
understand the management features it provides.
 Document Analysis: To get information about background of the system project team
review necessary documents, books that support this project. To make this project
more feasible and structured the team are analysing other thesis management websites
from universities other in our country and others, and internet for explanation about
some word definitions and for search books.

1.7.2 System Analysis and Design Methodology
Among the different methodologies available we are using object oriented methodology for
the analysis and design of our system. Object oriented methodology enables us to represent
complex relations among different objects and represent data and process with consistent
notation throughout the system. An important feature such as inheritance, polymorphism,
data hiding and encapsulation suits the design very well. This greatly improves the
communication among customers, analysers, designers and programmers. It increases
consistency among analyser, designer, implementation and testing. It also allows the
reusability of the code which will help to enhance the project in the future. To develop this
system water fall model system development methodology is usable. This Model was first
process model to be introduced. It is also referred to as a linear-sequential life cycle model. In
a waterfall model, each phase must be completed fully before the next phase can begin. At
the end of each phase, a review takes place to determine if the project is on the right path and
whether or not to continue or discard the project. In this model the testing starts only after the
development is complete. In waterfall model phases do not overlap. Waterfall approach is
preferred for the following advantages:
 This model is simple and easy to understand and use.
 It is easy to manage due to the rigidity of the model – each phase has specific
deliverables and a review process.
 In this model phases are processed and completed one at a time. Phases do not
overlap.
Analysis
Design
Implementation
Testing
Integration
Operation and
Maintainace
Figure 1:1 Waterfall model of system design

1.7.3 System Development Tools
We use the following software and software tools to develop our system. Some of these listed
as follows:
1.7.3.1 Hardware Requirement
Activities Tools
Training Papers
Writing Something Pen
Writing Soft copy of Documentation Part Computer (Desktop or Laptop)
Printing Purpose Printer
Storing File CD
File Transferring Flash 8 GB
Writing Something Pencil
Binding Purpose Binder
Table 1:1 Hardware requirements
1.7.3.2 Software Requirement
Activities Programs Why

Code Writing Dreamweaver, Notepad++ Easy to use
Database Server WAMP Server Database server for PHP
Web Server Apache (IIS) Web server for PHP
Server side Scripting PHP Understand by server
Client Side Coding HTML It works with PHP
Client Side Scripting JavaScript Easy way to validate form
Coding Language PHP Easy to writing code
Cascading Style Sheet CSS It works with HTML and PHP
Browsers IE, Mozilla Firefox, Google Better for displaying web
Chrome, Spark browser pages
Documentation MS Word 2010 Easy to use
User Training MS PowerPoint Best for presentation
Modelling and Scheduling Edraw, Visio 2013 Easy to design diagrams
Table 1:2 Software requirements
1.8 Project Management Technique

1.8.1 Project Schedule

Figure 1:2 Gantt chart
1.8.2 Project Budget

Resources like time and equipment are needed for any system development. Some of
resources needed for project team are listed below with their estimated cost.
No. Item Description Quantit Unit Unit Price Total price
y
1 Removable flash disk 2 Birr 150.00 300.00
2 Blank CD 5 Birr 6.00 30.00
3 Binding 2 Birr 20.00 40.00
4 Paper 1 pack Birr 70.00 70.00
5 Pencil 4 Birr 1.00 4.00
6 Pen 10 Birr 4.00 40.00
8 Printing 3 Birr 50.00 150.00
Total 634.00
Contingency 31.70
Grand Total 665.70
Table 1:3 Project budget
1.8.3 Project Breakdown

In project team every task must be done by every person of the group, so the group
participates on every stage of planning, analysis, and design of this project by sharing ideas.

Since entire member of the team exist at the same level or responsibility to do the project, for
reviewing each other work, to reduce time consumption, to make the member fully
knowledgeable & to increase the project quality, project group organization is based on
Decentralized control Team organization.
Project Graduates Credential Verifications for Madda Walabu University
Title
No Name Id No Mob. Phone Responsibility
1 Aliya Hassen EISR/0667/05 0917465890 Assistant Project
Leader, Project
Prepared by
Designer
2 Bayisa Guta EISR/0670/05 0919370911 Project Leader,
Programmer
3 Geleta Mosisa EISR/0682/05 0917639375 System Tester
4 Sosina Yared EISR/0700/05 0961025804 System Analyst
Table 1:4 Table of project breakdown
The technical team of this project comprises 4 Information Systems B.Sc. undergraduate
students with experience of doing different mini projects. The ultimate objective of the team
members is to develop a reliable and proficient verification and service system for graduated
students.
1.8.4 Risk Analysis, Identification, Mitigation and Monitoring
1.8.4.1 Risk
 Virus attacks the file used for development.

 If a team member leave the project or faces an issues.

 If miss installation or configuration with the development tools occur.
 If connection or internet is fail in this campus.
 If there may not some development tools.
 The tool cost may increase during development.
 There may be holy days and vacations to miss the project activity days.
 The developing tools may not exist or live out.
 The internet may not available in the campus.
 The adviser may be have limited time in order to advise the team.
 The group member may be health problem or sickness.
 The developing tools may increase cost or cost variation.
 There may miss-configure the server setups.
 There may some conflict in our country.
1.8.4.2 Mitigation
 Data loss happens, so the team uses different back up techniques through our daily
activity in the project.
 The project is not completed on schedule so the other group members cover those
parts.
 The development tools not working so re-configure the setup.

 Impossible to continue without development tools so we may buy tools depend on
condition necessity.
 It is difficult for project team but buy tools at immediate in the development time.
 There may be no Wi-Fi connection in the campus. So use mobile data to get some
additional information or guide from the internet.
1.8.4.3 Monitoring
 We will finish this project with the given schedule.

 We use the development tools in the table 1 above.
 The internet is available in the campuses at all days.
 The adviser have great role in this project success.
 We will meet at all project activity days.
 We will think all the developing tools are available.
 We will think the developing tools not increment cost.
 We will suggest we configure full setup (server).
2 REQUIREMENTAL SPECIFICATIONS
2.1 Functional Requirement

Functional requirements drive the application architecture of a system. A requirement
specifies a function that a system or component must be able to perform. Functional
requirements specify specific behaviour or functions[ CITATION htt \l 2057 ][ CITATION Ste03 \l
2057 ]. The functional requirements of the proposed system are listed as follows:

 Authenticate and authorize users according to user’s role.
 The system should check all the supplied user input.
 Enables administrator to manage the users.
 The companies or organizations must to register itself profiles to verify certificates.
 The system should give the facility to view detail information, add, edit, and delete
graduates information for the users such as administrator or director of registrar.
 Provide application form, same as the existing system, for the graduates to apply for
academic credentials.
 Provides facilities to download the academic credentials as per the requests from the
graduates.
 The companies or organizations can enter requests but cannot approve or delete
requests.
 Members of the Registrar group can approve a request but cannot delete requests.
 Members of the Administrators group cannot approve requests but can delete
requests.
 The admin can insert, update and search graduates information.
 Members of the finance officers can download fee receipt and enter approval or
disapproval remark but cannot delete any request.
 Data redundancy is avoided, through the proper design of the database.
 The system must provide help for the user.
2.2 Non-Functional Requirements

Non-functional requirements describe user-visible aspects of the system that are not directly
related with the functional behaviour of the system that are listed above. A non-functional
requirement is a statement of how a system must behave; it is a constraint upon the systems
behaviour. They specify criteria that judge the operation of a system, rather than specific
behaviour[ CITATION Ste05 \l 2057 ]. Non-functional requirements of the proposed systems are
listed as follows:
 Accessibility: The system available to the users 24 hours if internet connection and
electric power is exist.

 Performance: The system shall perform its operations within a minimum amount of
time. The system shall be interactive and the user gets the expected result within few
seconds. The system will be accessed by many users inside or outside the university.
For better response and throughput it should be given more emphasis for the faster
access to the system across the network. Constraints can be user’s computer low
RAM, Network or connectivity failure, and others.
 Security and Access permissions: Administration part of the system is accessible
only for the authorized Administration staff according to their Assigned right. An
Unauthorized user should not access the administration page by any means. Some of
the resources and activity shall be restricted and allowed only for authorized users.
Therefore the system shall have user identification method and it should grant or deny
access to users as per the privilege of the prospective user. There may be some
intruders who could access the file or data on the database, but with the proposed
system being part of MWU server this shall be a very rare occasion.
 Deployment: Final system shall be deployed in a web server (Apache) part of MWU.
 Documentation: The activities and outputs of each system development stage in the
project work flow will be properly documented for the successful completion of the
project. These documents produced at the end of each stage shall be organized and
compiled together at the end of the project for future reference, system maintenance,
and system support.
 Extensibility: Adding features and carry-forward of customizations at next major
version upgrade along with the business re-engineering is possible.
 Backup: There shall be a frequent and full back up mechanism to avoid any
information loss and inconsistency.
 User interface: The user interface of the system shall be user friendly and easy
enough to work with. System provides web interfaces that are compatible with
browsers like Internet explorer, Mozilla Firefox, Google chrome.
 Communication Interface: The MWU GCVS will be connected to the local area
network of MWU.
2.3 Feasibility Analysis

Feasibility analysis is an analysis and evaluation of proposed project to determine if it is
technically feasible, feasible within the estimated cost, feasible within political and feasible
within operation[ CITATION htt4 \l 2057 ].

2.3.1 Economic Feasibility
The purpose of assessing economic feasibility is to identify the financial benefit and cost
association with the development project, economic feasibility is referred to us cost benefit
analysis.
No. Item Description Quantity Unit Unit Price Total price
1 Removable flash disk 2 Birr 150.00 300
2 Blank CD 5 Birr 6.00 30
3 Binder 2 Birr 20.00 40
4 Paper 1 pack Birr 70.00 70
5 Pencil 4 Birr 1.00.00 4
6 Pen 10 Birr 4.00 40
8 Printing 3 Birr 50.00 150
TOTAL 634.00
Table 2:5 Economic Feasibility
2.3.2 Technical Feasibility

The system can be technically feasible because the technical resources need to develop,
install and to operate is available in the present infrastructure. It doesn’t require any technical
expertise and can be integrated with the existing system.
2.3.3 Political Feasibility
The system provides online verification and manages service related to graduated students,
which is more convenient to use for graduated students and registrar workers in MWU. This
will provide a good communication among the outside organization and MWU. The system
“MWUGCVS” will be a significant contribution to the development endeavours of our
country and supports the rule and regulation of the government hence it’s politically feasible.
2.3.4 Operational Feasibility

The system can be used effectively after it has been developed. Users will not have any
difficulty with the new system, producing the expected benefits. System will be developed
based on the policies of the university plus the new business rules.
3 SYSTEM ANALYSIS
This chapter covers the functional aspect of analysis that is functional modelling. The set of
functional requirements that have to be analysed is done in an object-oriented way. UML
(Unified Modelling Language) an object-oriented, graphic language, is unified for all the
aspects of the requirement analysis. The functional model consists of use case modelling to
show the system functionality from user point of view, use case description, activity diagram
to describe the details of internal system functioning and sequence diagram, collaboration
diagram and state chart diagram.
3.1 Actor and Use Case Identification

Actors Use case
 External user  Login
 Administrator  Request Certificate Verification

 Registrar  View Certificate Verification Link
 Finance  Manage Graduate Information
 Create and Manage Account
 Registration of Employee
 Approve Service Request
 Accept Payment
Table 3:6 Actor and use case identification
3.2 Use case Diagram

Use case diagrams are ideal artefacts to capture the requirements the system. They represent
the user requirements gathered during requirement elicitation. Use case diagram consists of
use cases, actors, and their relationship and system boundary[ CITATION htt7 \l 2057 ].
When we draw use case we use the following shapes.
No Shapes Representation
It represents the users of systems known as actors. It
1 represents a role that a user can play but not specific
user.
It represents a user goal that can be achieved by

2 accessing the system or software application.
It represents scope of systems. Known as system
3 boundary. The use case of a system is placed inside
this, while the actors who interact with the system are
put outside the system.

It represents that a use case contains the behaviour
4 defined in another use case.
<<include>>
It represents how and when the behaviour defined in
5 the extending use case can be inserted in to the
<<extend>>
behaviour defined in the extended use case.
It is used to associate actor and use case to indicate
6 that the actor participates in that use case. Therefore,
an association correspond to a sequence of actions
between the actors and use case in achieving the use
case.
Table 3:7 Use case representations

Request Certificate Registration of
Association
Verification <<include>> Employer
Registrar
External User View Certificate
Verification Link Association
Approve
Manage Graduate <<include>> Service Request
Information <<include>>
Association
Login <<extend>>
Create and Manage <<include>> <<include>> Association

Accept Payment
Adminstrator Account
Finance
Figure 3:3 Use case diagram

3.3 Use Case Description
Use Case ID Use Case Name Description
UC_01 Log In It describes the process of authenticating the user
name & password before granting access to his or
her
GCVS account.
UC_02 Request Verify It describes the process of starting verifying the
Certificate graduated student’s credentials.
UC_03 Manage Graduate It describes the process of updating, inserting,
information removing, searching data or files related to the
graduate’s credentials.
UC_04 Accept Payment It describes the process of verifying and accepting
the application fee for the service request of the
organizations or companies by the finance officer.
UC_05 Approve Service It describes the process of verifying & approving the
Request service requests of the organizations or companies
by the director of registrar.
UC_06 Create or Manage It describes the process of creating or managing
Accounts account for the authorized users of the system like
director of registrar or finance officer.
UC_07 Registration of It describes the process of registration of the
Employer employer and company or organization details with
the university in order to verify the candidate’s
credentials.
UC_08 View Certificate It describes the process of viewing a certificate
Link verification that sends to external user throw their
email.
Table 3:8 Use case descriptions
Use Case ID UC_01

Use Case Name Log in
Primarily Actor Administrator, Registrar, Finance.

Description It describes the process of authenticating the user name & password
before granting access to his or her GCVS account.
Trigger Administrator, Registrar and Finance and need to login his or her
account to use this system.
Pre-Condition Administrator, Registrar and Finance login.
Normal Action Actor’s Action System Response
 Step 1: Administrator,  Step 2: The system displays the
Registrar and Finance login page.
initiate to login.  Step 4: System checks the
 Step3: Administrator, authentication of username and
Registrar and Finance password.
enter a valid user name &  Step 5: System displays their
password. corresponding GCVS user page.
Post condition Administrator, Registrar and Finance can do different activities
depending on the permission provided to them.
Alternative  Step 4: If the username and password is not valid, system
Action displays error message and go to step 2.
Table 3:9 Use case descriptions for login
Use Case ID UC_02

Use Case Name Request Verify Certificates.
Primarily Actor External User.
Description It describes the process of requesting verify the graduate’s credentials.
Trigger External User want to request verify their credentials.
Pre-Condition Companies’ should register itself and graduates profiles.

 Step 1: External User  Step 2: The system displays the
initiates to requesting Requesting form.
verification.  Step 4: Systems validate information
 Step 3: External User submitted.
enters the  Step 5: System sends the certificate
organization details verification link throw the email.
and graduates  Step 6: System store the user’s
profiles. information and activity.
Post condition External user read Certificate Verification link
Alternative  Step 4: If entered information is not valid the system displays
Action error message and go to step 2.
Table 3:10 Use case description for verify certificates
Use case ID UC_03

Use case name Manage Graduate student information.
Actor Administrator, Registrar.
Description It describes the process of updating, Searching, adding, removing data or
files related to the graduated students files or credentials.
Trigger Administrator or Registrar wants to Searching, updating, delete, add
information.
Precondition Administrator or Registrar has to be remembering user name and
password.
Normal Actor’s Action (for update) System Response

Action  Step 1: Admin or Registrar initiates for  Step 2: System
Searching information. displays Manages
 Step 3: User clicks Manages Graduates Graduates
information link. The user can update, information link.
search, delete, view, and insert their task.  Step 5: System asks
 Step 4: Here user clicks the search to enter the student
option. ID.
 Step 6: User enters the student ID and  Step 7: System
clicks OK. displays the searched
Step 8: User View information Searched. information about
the student.
Post condition User uses the searched information.
Alternative  Step 9: If ID entered violates the data entry rules, searching fails and
Action informs the user.
Table 3:11 Use case descriptions for insert, update search, and delete graduates
information
Use case ID UC_04

Use case name Accept Payment.
Actor Finance officer.
Description It describes the process of approving the payment of students.
Trigger Finance officer wants to check and approve payment of graduates.
Precondition Finance has to be remembering user name and password.
 Step 1: Finance initiates for  Step 2: System displays the
approving payment. List for approval of
 Step 3: User clicks the List for payment link.
approval of payment link.  Step 4: System displays the
 Step 5: User downloads and list of student’s requests for
verifies the receipt, confirms with different services, along
the bank. with the fee details they

 Step 6: Users enter approved submitted.
remark and submit.  Step 7: System updates the
database, with the user’s
remark.
Post condition Database is updated by finance officer’s remark. Service request waits
for Registrar’s approval.
Alternative  Step 5: If confirmation fails, user updates the database with rejected
Action remark, followed by reason.
Table 3:12 Use case description for accept payment
Use Case ID UC_05

Use case name Approves Verification Service Request
Actor Director of Registrar
Description It describes the process of verifying & approving the Verification
service requests of the organization or companies by the director of
registrar.
Trigger User wants to check and approve Verification service requests of
Organization or companies.
Precondition User has to login.
 Step 1: User initiates  Step 2: System displays the List for
for approving requests. approval of service request link.
 Step 3: User clicks the  Step 4: System displays the list of
List for approval of Organization or Companies requests
service request link. for different Verification services,
 Step 5: User verifies along with the fee details submitted by
the data, remark of students.

finance.  Step 7: System updates the database,
 Step 6: Users enter with the user’s remark.
approved remark and  Step 8: System generates requested
clicks to generate document.
report based on the  Step 9: System displays the report for
request. the user with option for further entry
 Step 10: User views option.
the report and enters  Step 11: Systems save the report to
his remark and clicks the database and sends credential
save. verification link to organization.
Post condition External user or organization views the certification Verification link.
Alternative  Step 5: If confirmation fails, user updates the database with rejected
Action remark, followed by reason. Mail is send to the requested External
user or organization.
Table 3:13 Use case description for approve verification service request
Use Case ID UC_06

Use Case Name Create Account
Actor Administrator
Description It describes the process of creating a new mail account for the users by
the administrator.
Trigger Administrator needs to create an account for the user to use the
system.
Pre-Condition The Administrator who knows the administrator password should
login as and use the create account facility in the system.
 Step 1: The Administrator  Step 2: The system displays
initiate to login. the login page.
 Step 3: Administrator enters  Step 4: System checks the
valid user name & password. authentication of username and
 Step 6: From the admin page password.
Create Account Option is  Step 5: System displays admin
selected by the page.
Administrator.  Step 7: System displays create
 Step 8: System administrator account page.
enters user information.  Step 9System creates user

account.
Post condition New user account is created which the user can use for different
activities.
Alternative  Step 4: If the username and password is not validated and verified,
Action system displays error message and go to step 2.
 Step 8: If the user information is not validated and verified,
system display error message and go to step 7.
Table 3:14 Use case descriptions for create or manage account
3.4 Sequence diagram

Sequence diagrams show a succession of interaction between classes or object instances over
time. It also shows the processing described in a single scenario. It describes interaction
among classes in terms of an exchange of message overtime. It is a good way to visualize and
validate various runtime scenarios.[ CITATION htt1 \l 2057 ]
When we draw sequence diagram we use the following shapes.
It describes the way an object will
1 behave in context
Known as activation box, used to

2 represent the time an object needs to
complete a task.
It is a message that represents
3 communication between objects.
Lifelines that represents the objects
4 presence overtime
Reply message that represents
5 message is back to the original
lifeline
A message that an object sends to
6 itself.
Delete icon that represent destruction
7 of object.

Table 3:15 Shapes of sequence diagram
Sequence Diagram for Login

:User :Login :Login :System :User Account
<<Actor>> <<UI>> <<Controller>> <<Server>> <<UI>>
1: Wants to
login to the
2: Enter user 3: Request for
system
name and validation
password
5: Invalid User name and
Password 4: If Invalid
6: Access
User Account Page Displayed
Figure 3:4 Sequence diagram for login
Sequence Diagram for Requesting Academic Service

System
External User User Profile Request Service Service Request Page
<<Database
<<Actor>> <<UI>> <<Controller>> <<UI>>
Server>>
1: Initiate for
Service request 2: Click Request
Service
3: Access
4: Display application Form
5: Fill Application 6: Validation
8: Send 9: Validation
7: Display Error Message
10: Acknowledgent Message

Displayed
Figure 3:5 Sequence diagram for requesting academic service
Sequence Diagram for Accept Payment for Service

:Payment :Payment Approval
:Finance :User Profile :Database
Approval Page Page
<<Actor>> <<UI> <<Server>>
<<Controller>> <<UI>>
1: Initiate
2: Click Check
Payment
3: Access
5: Fill the Information for Approval
4: Approval Page Display

6: Validation
7: Error Message Displayed

8: Approved
9: Confirmation Message Displayed
Figure 3:6 Sequence diagram for accept payment for service
Sequence Diagram for Approving Services

:Registrar :User Profile :Approval List :Approval Page :Database
<<Actor>> <<UI>> <<Controller>> <<UI>> <<Server>>
1: Initiates 2: Click List

for Approval 3: Access
4: Approval Page Displayed
5: Check the required Information
6: Enter Information to Generate Report

7: Validation
8: Error Message Displayed 10: Verify

9: Generate for and
Report
Generation Generate
Report
11: Report Generated
Figure 3:7 Sequence diagram for approving services (for credentials from
graduates)
Sequence Diagram for Verify Certificates

:Verification :System :System
User :User Profile :Verify
Page <<Application <<Database
<<Actor>> <<UI>> <<Controller>>
<<UI>> Server>> Server>>
1: Initiate
For 2: Click Verify
Verification 3: Access
4: Display Verification Page
5: Fill the Application Form 6: Validation

9: Access
7: Display Error Message Data for
8: Verify
Verification
10: Retriving Data
11: Display the Required Information
Figure 3:8 Sequence diagram for verify certificates
Sequence Diagram for Searching Graduates Information from the Database.

:System :System
Admin :Admin Profile :Search :Data Search
<<Application <<Database
Server>> Server>>
1: Initiate
For 2: Click Search
Searching 3: Access
4: Display Data Search Form
5: Enter Student ID 6: Validating the Data
7: Display Error Message

8: Information Send
9: Send
10: Verify
11: Display the Information
Figure 3:9 Sequence diagram for searching graduates information from the
database
Sequence Diagram for Create Account

:Server
:Admin :User Profile :Create Account :Create Account
<<Database
Server>>
1: Initiate for
Create Account 2: Click Create 3: Access
Account
4: Display Create Account Form

5: Fill Account Form 6: Validate
7: Error Message
8: Send
9: User Account Created Successfully
Figure 3:10 Sequence diagram for create account
3.5 Collaboration diagram

A collaboration diagram, also called a communication diagram or interaction diagram, is an
illustration of the relationships and interactions among software objects in the Unified

Modelling Language (UML). Collaboration diagrams are best suited to the representation of
simple interactions among relatively small numbers of objects. As the number of objects and
messages grows, a collaboration diagram can become difficult to read .It is used to show
some data flows between objects and the interaction caused between them [ CITATION htt3 \l
2057 ]. Some of the data flows among objects were explained below.
Collaboration Diagram for Login
Figure 3:11 Collaboration diagram for login
Collaboration Diagram for Requesting Service

Figure 3:12 Collaboration diagram for requesting service
Collaboration Diagram for Verify Certificates

Figure 3:13 Collaboration diagram for verify certificates

3.6 Activity diagram
Activity diagram is one of the UML elements which used for business process modelling and
used for modelling the logic captured by single use case usage scenario. It also helps to
model the internal logic of complex operations of the system. In addition to this, it shows the
work flow from start point to end point details and many decision parts that exist in
progression of event contain in activity. Generally activity diagram is essentially a flowchart,
showing flow of control from activity to activity [ CITATION htt6 \l 2057 ]. When we draw
activity diagram we use the following shapes.
Join symbol, represent when two con-current
1 activities combined
Fork symbol , represents splitting of two

2 activities into two concurrent activities
Connector symbol that represents directional

3 flow, or control flow of the activity
Indicates the activities that make up a modelled

4 process.
It is start symbol that represents the beginning of
5 a process or work flow.
It represents a completion of a process or

6 workflow.
Diamond shape represents the branching or

7 merging of various flows with the symbol acting
as the frame or container.
Table 3:16 Representation of activity diagram
Activity Diagram for Login

<<UI>>
User Login Page
Enter User ID
and Password Cancel Operation
<<Controller>>
NO Login
Display the
YES Requested Page
Figure 3:14 Activity diagram for login
Activity Diagram for Certificate Verification Request

<<UI>>
Service Description Page
<<Controller>>
Select Required Service
Fill The Application Form

Cancel
<<Controller>>
Submit
Invalid Valid
Send Stored Basic Display
Display Error
Information For Confirmation
Message
Approval Message
Figure 3:15 Activity diagram for certificate verification request
Activity Diagram for Accept Payment

<<Controller>>
Display Finance
Link
Click list for Verify the

Approval Payment Receipt
NO
Not Approved Approved
YES
Enter Remark
and Submitt it
Remark
Submitted to
Database
Figure 3:16 Activity diagram for accept payment
Activity Diagram for Approve Service by the Registrar Director

<<Controller>>
Display Registrar
Interface
<<Control>>
Clickk List for
Approval
Verify the Request

and Finance Remark Cancel
Send Message to
External User
Invalid
Store the Report of

Generate Report as Approval and Remark
per Request and
Enter the Remark Valid Mail the Report to
External User
Figure 3:17 Activity diagram for approve service by the registrar director
Activity Diagram for Verify

<<Controller>>
Certificate
Verification
Display Cancel
Application Form
Fill the
Application Form
Invalid
Valid
Display the Required

Graduated Student
Information
Figure 3:18 Activity diagram for verify

Activity Diagram for Search, Update, Delete and Insert (Manage Graduate
Information).
<<UI>
Display Admin Page
<<Controller>>
Click Search
<<UI>> Display Data Not Exist

Cancel Display Search Form Message
NO
Enter Search
Parameter
YES
Display
Information from
Database
Figure 3:19 Activity diagram for search, update, delete and insert (manage graduate
information)

Activity Diagram for Create or Manage Account.
<<UI>>
Admin Page
Displayed
<<Controller>>
Click Create
Acount
Display Create
Cancel Account Form
Enter Username Display Error

and Passwor NO Message
YES
Account Created
Figure 3:20 Activity diagram for create or manage account

3.7 State Chart Diagram
The state diagram depicts the state of objects as their attributes change from one state to the
other state. State chart modelling is used to show the sequence of states that an object goes
through and the events that cause the transition from one state to the other actions that result
from a state change[ CITATION htt5 \l 2057 ]. The following figure shows the state of the
objects that corresponding use cases. Some of them are:-
State Chart Diagram for Login
Select login page

from home page
Enter Username
and Password
Error Message
Displayed
CHECK USERNAME
NO
AND PASSWORD
Validate
YES
Login to the LOGOUT

System
Figure 3:21 State chart diagram for login

State Chart Diagram for Certificate Verification
Select Request Form
Register Employee
and Company
Send Request
D isprove d
Request Stored on
Database
Send to Approval Page
Approve
U n V erified
Approved
Verify
Compare saved
and Entered data
Report is
Generated
Verified
Validate Generate Report
Figure 3:22 State chart diagram for certificate verification
State Chart Diagram for Request Service

Select
Request UI Page
Display
Request UI
Page Displayed
Enter Data
Fill Request
Form
Send
Data is Stored on End

Database
Figure 3:23 State chart diagram for request service
State Chart Diagram for Administrator Page

Select
Home Page
Get Login Page

M es sa g e E rr o r
Enter Username
and Password
No Login
In s e, rUt p d a t e a n d
Validate
D e le t e D a t a
Yes
Manage Gradaute Logout

Information
Figure 3:24 State chart diagram for admin page
4 SYSTEM DESIGN
System design is the transformation of analysis models of the problem space into design
models (based on the solution space)[ CITATION Haw94 \l 2057 ].

In this chapter we are going to describe the detailed description which focused on System
design and system containing class diagram, deployments diagram, components diagram and
user interface prototype. Object oriented system development methodology is used in this
project. It incorporates two principle phases.
 Improve the use case model to reflect the implementation environment.
 Model objects interactions and behaviours that support the use case scenario or
discretion.
The following section provides the Class diagram, Deployments diagram, and Components
diagram and User interface prototype. This will help us to design the system and describe
how its interface looks like.
4.1 Class Diagram

Class modelling used to describe the structure of the system. Classes are abstractions that
specify the common structure and behaviour of a set of objects in the new system. In this
modelling the team’s members have design the system in terms of objects, classes, attributes,
operations and their association[ CITATION htt11 \l 2057 ] . Of course the model depicted here is
a sample.

Figure 4:25 Class diagram
4.2 Deployments Diagram

The deployment diagram also helps to model the physical aspect of an object-oriented
software system. It models the run-time configuration in a static view and visualizes the
distribution of components in an application. In most cases, it involves modelling the

hardware configurations together with the software components that lived on. Deployment
diagram would show what hardware components (nodes) exist[ CITATION htt10 \l 2057 ].
Examples
 Web server.
 Application server.
 Database server.
Deployment modeling used to show the hardware of the system, the software that is installed
in the hardware and also the middleware that is used to connect the disparate machines to one
and other. It also shows how the software and the hardware components work together.
Client Machine
:Chrome TCP/IP
Web Server Admin
:E xp l o r e r
:WAMP
:Mozilla
PHP
Central Data Base
:MYSQL
Figure 4:26 Deployment diagram
Description of the architecture deployment of the system is described as follows.
Clients are responsible for:-

 Provide user interface to the user enabling to get services.

 Receiving inputs from user.
 Checking range of performance.
 Initiating database transactions once all necessary data are collected in the system.
Server said responsible for:-
 Transaction performance.
 Guaranteeing the integrity of data.
 Putting backup of the database.
4.3 Components Diagram

In the Unified Modelling Language, a component diagram depicts how components are wired
together to form larger components or software systems. The component model illustrates the
software components that will be used to build the system. These may be built up from the
class model and written from scratch for the new system. And also this modelling

components of the system will be wired showing that there is relation among components,
this in some extent shows which components or objects will be accessed by whom[ CITATION
htt9 \l 2057 ].
Figure 4:27 Component diagram
4.4 User Interface Prototype

User Interface Prototype is an iterative analysis technique in which users are actively
involved in the mocking-up of the UI for a system. A user interface prototype is a vehicle for
user to communicate the possible UI design of system[ CITATION htt8 \l 2057 ].

HOME
PAGE
External User Admin Finance Registrar
Login Login Login
Manage Manage Graduate

Request Certificate Graduate Information List of Approval Information
Verification Payment
Add Graduates Update Graduate
information Information
View List of Approved
Acknowledgement View Graduate Payment
message Request Approve Service
Request
View
Verification Link Temporary
Create Account
Report
Report
Original Degree
Report
Figure 4:28 User interface prototypes (design)

GRADUATES CREDENTIAL
VERIFICATION
SYSTEMS FOR MADDA WALABU
UNIVERISTY
Home Page External User Admin Registrar Finance About Us Help
USER NAME:
PASSWORD:
ROLE: Select one V
Login Clear
Madda Walabu University
WEL COME TO GRADUATES

If you want to create new
CREDENTIAL VERIFICATION account click Here
SYSTEMS FOR MADDA
WALABU UNIVERSITY
Copyright © 2016 MWU Graduate Credetials Verification. All rights reserved.
Figure 4:29 User interface prototype (snapshot)

CONCLUSIONS
With all the accumulated effort invested, there are reasons to believe that at the end of the
project “Graduated Credential Verification System for Madda Walabu University” ﬁnd’s
itself in a better shape. We summarize the progress with respect to the main objectives of the
project. Our team members can conclude the following perception views as we have done the
project throughout this year. As we know, the value of every degree is the reputation of the
institution and the students produced, the greatest obstacle to any academic institution is
dishonesty and forgery which has to be balanced with verification and authentication systems
and processes. In the aspect of credentials verification system there is a vast scope and is
seemed to be a must. More or less keeping track of what our verification system (manual) is,
what are the different possibilities in the field of monitoring, verifying certificates (graduate)
issued from MWU and processing several academic requests from the companies in the
future and especially different possibilities for controlling forgery related to documents,
certificate and studentship are there with GCVS for MWU and we have tried our level best to
reach the expectation level from graduate studies. GCVS for MWU is flexible, accurate and
attractive with easy GUI approach. Finally the team expects that the developed system will
change the general manual system of the MWU and it makes more reliable and efficient than
the previous manual system. We could accomplish the some of the key issues. But now there
is a clear and base idea how the system can be developed and integrated. This project can be
seen as an initiation for students who are doing project on the same field for nationalization
or generalization of certificate verification system for Ethiopia.
REFERENCES
1. [Online] http://www.mwu.edu.et.
2. [Online] https://en.m.wikipedia.org/wiki/Functional_requirement.
3. Stellman. Software Requirements. 2nd. s.l. : Microsoft Press, 2003. ISBN 978-0-596-00948-9.
4. Stellman, Andrew, Greene, Jennifer. Applied software Project Management. s.l. : O'Reilly Media,
2005. p. 113. ISBN 978-0-596-00948-9.
5. [Online] http://www.businessdictionary.com/definition/feasibility-study.html.
6. [Online] http://msdn.microsoft.com/en-us/library/dd409477.aspx.
7. [Online] http://www.smartdraw.com/sequence-diagram/.
8. [Online] http://refcardz.dzone.com/refcardz/getting-started-uml.
9. [Online] http://www.lucidchart.com/pages/uml-activity-diagram-symbols-meaning.
10. [Online] http://creately.com/blog/diagram-types-examples/.
11. Hawryszkiewycz, Igor T. Introductions to Systems Analysis and Design. s.l. : Prentice Hall PTR,
1994.
12. [Online] http://searchsoa.techtarget.com/definition/class-diagram.
13. [Online] https://en.m.wikipedia.org/wiki/Deployment_diagram.
14. [Online] http://www.uml-diagrams.org/component-diagrams.html.
15. [Online] http://agilemodeling.com/artifacts/uiPrototype.htm.

All Chapters

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

All Chapters

Uploaded by

Copyright:

Available Formats

TABLE OF CONTENTS

Graduates Credential Verification Systems for MWU Page

Graduates Credential Verification Systems for MWU Page

Tables Name Page

TABLE 1:1 HARDWARE REQUIREMENTS----------------------------------------------------------------------------------------------------10

Graduates Credential Verification Systems for MWU Page

Figures Name Page

FIGURE 1:1 WATERFALL MODEL OF SYSTEM DESIGN.........................................................................................................9

Graduates Credential Verification Systems for MWU Page

Graduates Credential Verification Systems for MWU Page

Graduates Credential Verification Systems for MWU Page

CGPA Cumulative Grade Point Average

ERD Entity Relationship Diagram

GUI Graphical User Interface

GVCS Graduates Credential Verification Systems

HTML Hypertext Mark-up Language

IIS Internet Information Service

MWU Madda Walabu University

MWUGCVS Madda Walabu University Graduates Credential Verification Systems

MySQL Structured Query Language

PHP Hypertext Pre-processor

RAM Random Access Memory

TCP Transmission Control Protocol

UML Unified Modelling Language

WAMP Windows Apache MySQL PHP

Graduates Credential Verification Systems for MWU Page

Graduates Credential Verification Systems for MWU Page

Graduates Credential Verification Systems for MWU Page

Graduates Credential Verification Systems for MWU Page

Graduates Credential Verification Systems for MWU Page

Graduates Credential Verification Systems for MWU Page

Graduates Credential Verification Systems for MWU Page

Graduates Credential Verification Systems for MWU Page

Graduates Credential Verification Systems for MWU Page

Figure 1:1 Waterfall model of system design

Graduates Credential Verification Systems for MWU Page

1.7.3.1 Hardware Requirement

Table 1:1 Hardware requirements

1.7.3.2 Software Requirement

Activities Programs Why

Table 1:2 Software requirements

1.8 Project Management Technique

Graduates Credential Verification Systems for MWU Page

1.8.2 Project Budget

Graduates Credential Verification Systems for MWU Page

Table 1:3 Project budget

1.8.3 Project Breakdown

Graduates Credential Verification Systems for MWU Page

Table 1:4 Table of project breakdown

1.8.4 Risk Analysis, Identification, Mitigation and Monitoring

 Virus attacks the file used for development.

Graduates Credential Verification Systems for MWU Page

Graduates Credential Verification Systems for MWU Page

 We will finish this project with the given schedule.

2.1 Functional Requirement

Graduates Credential Verification Systems for MWU Page

2.2 Non-Functional Requirements

Graduates Credential Verification Systems for MWU Page

2.3 Feasibility Analysis

Graduates Credential Verification Systems for MWU Page

Table 2:5 Economic Feasibility

2.3.2 Technical Feasibility

Graduates Credential Verification Systems for MWU Page

3.1 Actor and Use Case Identification