ADDIS ABABA INSTITUTE OF TECHNOLOGY

CENTER OF INFORMATION TECHNOLOGY AND

SCIENTIFIC COMPUTING

SOFTWARE ENGINEERING PROGRAM

PROJECT DOCUMENTATION ON THE

NATIONAL DOCUMENT VERIFICATION SYSTEM

Team Members: - Natnael Belete: ATR/3997/05

Natnael Zeleke: ATR/2891/05
Hermon Amha: ATR/5904/05
Megdelawit Kendie: ATR/2747/05

ADVISOR: Tigabu Dagne

Date: February 2017
 ADDIS ABABA INSTITUTE OF TECHNOLOGY

CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC

COMPUTING

SOFTWARE ENGINEERING PROGRAM

PROJECT DOCUMENTATION ON THE

NATIONAL DOCUMENT VERIFICATION SYSTEM

This Project documentation submitted in partial fulfillment of the requirements for the
Degree of Bachelor of Science in Software Engineering.

Name and signature of Members of the examining board:

Name Title Signature Date

1. __________________ Advisor _____________ _____________

2. __________________ Chairperson _____________ _____________

3. __________________ Examiner _____________ _____________

4. __________________ Examiner _____________ _____________

5. __________________ Examiner _____________ _____________

February 2017
 Declaration of Originality

We declare that this project is our original work and has not been presented for a degree in any
other university.

Name Signature Date

1. Natnael Belete __________________ __________________

2. Natnael Zeleke __________________ __________________

3. Hermon Amha __________________ __________________

4. Megdelawit Kendie __________________ _________________

This project documentation has been submitted for examination with my approval as university
advisor:

Tigabu Dagne _________________________

February 2017
 ACKNOWLEDGMENT

First of all we are grateful to God for helping us get to this moment, complete first phase of this
project.
Then we, the project team, wish to express our sincere thanks to Mr. Tigabu Dagne, Advisor of
this project, for providing us with all the necessary help for the project, for his motivation,
advises and suggestions.
We also take this opportunity to express gratitude to all the center for Information Technology
and Scientific Computing (ITSC) and also the final year project committee for examining the
proposed system and giving us the opportunity to develop it. We would also like to thank other
instructors and staff members for enabling us to use the available resources of the center.
 ABSTRACT

National document verification system will be a national online system that will allow
governmental and non-governmental organizations to compare documents with a saved record
on a repository system using image processing. The system will help speed up document
verification processes and help eradicate manual verification errors thus reducing the impact of
false or forged documents.
There are various document verification systems around the world. Examples include ARH,
DVS and direct verify which are all automated.
In Ethiopia the only computerized fast and reliable system that checks the validity of a document
is the ministry of education. Used for grade 10 and 12 national exam result certificates only.
Ethiopian document authentication, registration and record keeping supervision also works on
document verification. However their document verification system is manual. This manual
process is not only unreliable but also costly of time, space and human power.
Currently in Ethiopia people are getting fake documents in easy access without going through
any sort of the required procedure. This is depriving the qualified citizen of their opportunities
and giving courage to the young adults by giving them an easy way out but the wrong way
indeed.
The project team proposes the NDVS system that will try to ease the problem of verifying the
originality of a document in easy and accessible way. This system will create a trustworthy
environment with an easy access for anyone with the need to verify any form of document.
The NDVS system will provide a means by which users can verify the legitimacy of the hard
copy or softcopy of any sort of paper works, identifications and certificates online. The system
will also provide an online repository system by which all original documents can be issued to
recipients online and where the recipients can send the documents to organizations requiring
those documents. The system will be developed for documents of all formats.
The final product will be a web based system that will provide the above seen functions. The
system will be developed using Asp.net and the developing team will be using image processing
for the purpose of comparing images of documents.
The next phase of this project will be implementation, where the developing team will be
working on developing the full working model of the system.
Table of Contents

ACKNOWLEDGMENT.................................................................................................................4
ABSTRACT....................................................................................................................................5
List of Figures..................................................................................................................................9
List of Tables.................................................................................................................................10
ACRONYMS.................................................................................................................................11
Chapter 1: INTRODUCTION.......................................................................................................12
1.1 Background.....................................................................................................................12
1.2 The Existing system........................................................................................................13
1.3 Motivation.......................................................................................................................14
1.4 Statement of the problem................................................................................................14
1.5 Objectives........................................................................................................................15
1.4.1. General Objectives.......................................................................................................15
1.4.2. Specific Objectives......................................................................................................15
1.5 Proposed System..................................................................................................................15
1.6 Feasibility Study..................................................................................................................17
1.6.1 Technical feasibility......................................................................................................17
1.6.2 Economic feasibility.....................................................................................................17
1.6.3 Legal feasibility............................................................................................................18
1.6.4 Operational feasibility..................................................................................................18
1.7. Methodology.......................................................................................................................18
1.7.1 Data Gathering tools.....................................................................................................19
1.7.2 Implementation Tools and methods employed.............................................................19
1.8. Scope and limitations..........................................................................................................19
1.8.1 Scope of the project......................................................................................................20
1.8.2 Limitation.....................................................................................................................20
1.9 Project Management Plan....................................................................................................20
1.9.1 Time management plan.................................................................................................20
1.9.2 Quality management plan.............................................................................................21
1.9.3 Communication management plan...............................................................................22
1.10 Application of Results.......................................................................................................22
 1.11 Organization of the project................................................................................................23
Chapter 2: LITERATURE REVIEW............................................................................................24
2.1 Review.................................................................................................................................24
2.2 Summary..............................................................................................................................26
Chapter 3: SYSTEM REQUIREMENTS......................................................................................27
3.1 General Description.............................................................................................................27
3.1.2 Product Perspective......................................................................................................27
3.1.3 Product Functions.........................................................................................................27
3.1.4 User Characteristics......................................................................................................27
3.1.5 General Constraints......................................................................................................28
3.1.6. Assumptions and dependencies...................................................................................28
3.2 External Interface Requirements.........................................................................................28
3.2.1 User Interfaces..............................................................................................................28
3.2.2 Hardware Interfaces......................................................................................................29
3.2.3 Software Interfaces.......................................................................................................29
3.2.4 Communications Interfaces..........................................................................................30
3.3 Functional Requirements.....................................................................................................30
3.4 Use Cases.............................................................................................................................35
3.5 Non-Functional Requirements.............................................................................................41
3.5.1 Performance..................................................................................................................41
3.5.2 Reliability.....................................................................................................................41
3.5.3 Availability...................................................................................................................42
3.5.4 Security.........................................................................................................................42
3.5.5 Maintainability..............................................................................................................42
3.5.6 Portability.....................................................................................................................42
3.6 Inverse requirements............................................................................................................42
3.7 Design Constraints...............................................................................................................42
3.8 Logical Database Requirements..........................................................................................43
3.9 Other Requirements.............................................................................................................44
3.10 Change Management Process............................................................................................44
Chapter 4: SYSTEM DESIGN......................................................................................................45
4.1 General Overview................................................................................................................45
 4.2 Development Methods & Contingencies.............................................................................46
4.3 System Architecture.............................................................................................................47
4.3.1 Subsystem decomposition............................................................................................47
4.3.2 Hardware/ Software Mapping.......................................................................................48
4.4 Object Model.......................................................................................................................49
4.4.1 Class Diagrams.............................................................................................................49
4.4.2 Sequence Diagram........................................................................................................52
4.5 Detailed Design...................................................................................................................56
4.6 Activity Diagram.................................................................................................................66
Chapter 5: CONCLUSION AND RECOMMENDATION...........................................................68
5.1 Conclusion...........................................................................................................................68
5.2 Recommendation.................................................................................................................68
REFERENCES..............................................................................................................................69
APPENDIX A: Project Cost..........................................................................................................70
APPENDIX B: Glossary................................................................................................................71
 List of Figures
Figure 1: proposed system.............................................................................................................17
Figure 2: Gantt chart......................................................................................................................21
Figure 3: Use Case diagram for the Proposed System..................................................................36
Figure 4: High level Diagram........................................................................................................45
Figure 5: Components of the context and Data flow diagrams.....................................................46
Figure 6: Context Diagram............................................................................................................46
Figure 7: Data Flow Diagram Level 1...........................................................................................47
Figure 8: Subsystem Decomposition of Document service, Data Flow diagram level 2..............48
Figure 9: Deployment Diagram.....................................................................................................49
Figure 10: Class Diagram..............................................................................................................51
Figure 11 Sequence diagram- User Registration...........................................................................52
Figure 12: Company Registration sequence diagram....................................................................53
Figure 13: System Admin sequence diagram................................................................................53
Figure 14: Login Sequence Diagram.............................................................................................54
Figure 15: Add document sequence diagram................................................................................54
Figure 16: receive documents Sequence diagram.........................................................................55
Figure 17: Send Document Sequence diagram..............................................................................55
Figure 18: Verify document sequence diagram.............................................................................56
Figure 19: Activity Diagram..........................................................................................................66
 List of Tables
Table 1: Project Schedule..............................................................................................................21
Table 2 Communication table........................................................................................................22
Table 3: Cost Breakdown..............................................................................................................69
 ACRONYMS
CSS - Cascading Stylesheet

DVS- Document verification system

GUI – Graphical User Interface

HTML – Hyper Text Markup Language

HTTPS – Hyper Text Transfer Protocol Secure

HTTP – Hyper Text Transfer Protocol

JS – JavaScript

Matlab - Matrix laboratory

Moq – Mocking library

MVC- Model View Controller

NDVS- National document verification system

Phash - perceptual hash

Ui - User Interface
 Chapter 1: INTRODUCTION

1.1 Background

Document forgery is a critical and concerning issue all over the world [1]. Falsifying documents
is a crime [1]. It involves replacing, substituting or modifying a document for the purpose of
misleading another person. It can also involve transferring copies of documents that are known
to be false or forged. In many countries, falsifying a document is a crime punishable as a felony.
At this current era, where computers and printers have become widely available it has become
easier to produce high-quality forgeries [2]. According to [2] documents currently being falsified
include:
• Identification cards
• Bank statements and account records
• Immigration documents (for instance visas, passport etc.)
• Driver’s Licenses
• Birth certificates
• Educational Certificates (high school, college, university etc...)
• Medical certificates
Document verification is a process by which documents presented by individuals and prospective
employees are ensured of being genuine and that the holder is the rightful owner [3].
The proposed system referred hereafter as the National document verification system (NDVS)
will be a national online system that will allow organizations or users to automatically verify an
individual’s documents. This will help protect the government and businesses from identity
crime.
The NDVS will allow users to verify the authenticity of documents such as birth certificates,
driver licenses, educational transcripts, certificates and so on by crosschecking with a template in
the database.
The NDVS will also provide an online document repository where original documents will be
stored. There, documents can be issued to recipients online and the recipients can send their
original documents through the system to organizations requiring those documents when
applying for different types of services or benefits. Therefore eliminating doubts about the
documents because the recipients will not be able to tamper with it.
Basically the NDVS will permit users to verify documents over the internet, rather than in-store
in-branch or in-person. It will be a web based system that will improve procedures so that
documents can be verified by a simple and accurate way.
1.2 The Existing system

Currently in Ethiopia, document verification system is provided by the Ministry of Foreign

Affairs (MFA). Document verification services are provided when various organizations request
for authentication over the verification of doubtful documents [4].
Different type of documents issued by different institutes in Ethiopia are verified by their
respective bureaus of their city [4]. Some common cases are mentioned below
 Elementary school and high school transcripts:
Issued by educational institutes in Addis are certified by education bureaus of the city.
 Grade 10 and 12 general school leaving certificate examinations:
Certificates given after the completion of 10 th and 12th grade are authenticated by national
examination agency of Ethiopia.
 Education diplomas and certificates:
Diploma’s issued by regional technical and vocational training Institutes are
authenticated by regional and vocational agencies.
Diplomas and degrees issued by private colleges are authenticated by Addis Ababa
Technical and Vocational Agency and Higher Education Quality and Relevance Agency
respectively.
 Graduate and post graduate degrees from Ethiopian private universities:
Non-governmental institutions issued documents are authenticated by the Ethiopian
Higher Education Quality and Relevance Agency.
 Educational documents from Ethiopian public universities signed and sealed by the
relevant registrar office :
University issued documents are authenticated by registrar office of the issuing
institution.
 Medical certificates and other documents issued by medical institutions:
Medical institution issued documents are verified by the respective health bureaus.

1.3 Motivation

There is a gap to be filled in Ethiopia regarding document verification and little is being done to
tackle document forgery. Because of document forgery, honest citizens aren’t getting
opportunities they deserve while criminals succeed by using shortcuts.
The above seen problem and the growing need for an automated, fast and reliable verification
system is what motivated the developing team to do this project. By doing this project, the
development team hopes to decrease the impact of document forgery by putting the NDVS in
use.
1.4 Statement of the problem

Document fraud is costing many countries billions of dollars a year. The BBC World Service
reported in 2012 that the estimated value lost through fraud in the UK was $100 billion (£66
billion) a year. It is also estimated to cost Australia $1.6 billion each year [5].
The U.S. government's 2006 fraud review concluded that fraud is a significantly under-reported
crime, and while various agencies and organizations were attempting to tackle the issue, greater
co-operation was needed to achieve a real impact in the public sector. The scale of the problem
pointed to the need for a small but high-powered body to bring together the numerous counter-
fraud initiatives that existed [5]. It is difficult to get any quantitative information about the
problems created with fraud in Ethiopia. But it is clear that the country is facing numerous
consequences because of document fraud.
Currently in Ethiopia there are people that find it easier to just obtain fake documents than to go
through the required training and screening process needed to earn those documents. For
instance, lots of individuals are applying and being hired for jobs using their fake degrees, fake
diplomas and fake Ph.Ds. As a result qualified citizens are robbed of their opportunities and left
unemployed while the jobs are being done by unqualified frauds. This benefits people who don’t
deserve it and discourages people with legitimate documents.
Document authentication, registration and record keeping supervision is a governmental
institution that works on document verification in Ethiopia. However there document verification
system is manual. Some high governmental institutions also use the same method. They keep
additional certificates or document after issuing a deal or documents. So if someone wants to
check the validity of the document on another occasion, they will cross check the document to
the copy they saved to their database when they issued the document you presented, if they find
the copy they will verify document is original. This is time taking and error prone, since the
document is preserved physically and also searched physically. If there is any chance these
documents are destroyed by some reason, there is no way documents can be verified of their
originality. This manual work will cost time, space and human power. Not only does it cost all
these things but it is also unreliable. This will leave a big gap when it comes to verifying the
originality of documents.
The ministry of education has a computerized system that checks the validity of grade 10 and
grade 12 national test result certificates. These system checks the originality of documents by
fetching the scanned original certificate from the database. When students bring their certificates
and want their certificate to be verified or when they want to send their certificates to other
countries, the workers take their document, search their document from the database and cross
check the result on the certificate the student presented and the one on the database. If all the
results are correct they will add a stamp on the back of the certificate which says the document is
original. After that the students can send their documents to other countries. This process is fast
and reliable, but the system only works for this institution.
The proposed system plans to make this process inclusive to all institutions in a different and
easily usable method but towards getting the same goal. The NDVS will permit users to verify
their details over the internet.

1.5 Objectives

1.4.1. General Objectives

The general objective of the study is to provide a system by which organizations can verify the
legitimacy of legal documents online.

1.4.2. Specific Objectives

Specific objectives of this project are:

- To provide a way of checking the originality of documents
- To provide a way so that documents could be verified easily
- To provide a way to encode documents using NDVS system
- To provide a way to store documents in a reliable way
- To make the system be applicable for numerous type of documents
- To minimize and control falsified documents from being used.

1.5 Proposed System

The proposed system will try to alleviate the problem of verifying the originality of a document
in easy and accessible way.
The system will work by letting documents be uploaded online before the certificate is given to
the owner. When the document is uploaded information about the owner of the certificate will
also be filled; Email, Full Name, Field of study will also be filled before the certificate or
document is upload to database of the company. Here the email will act like the connection
between the user and the certificate. But the email is not necessary here; a document could also
be uploaded with another information like full name and field of study.
When a user signups with an email he/she will be asked to activate her account by logging to
their email. After activating their account; they will find documents that were issued to them
with their email account. They can send these documents to other companies that require their
documents. The sent document will also contain full information and contact of the document
issuer. Detail information about the document like date of the issuing and also the scanned image
of the original document will be included. The owner of the document cannot alter any kind of
data on the document. The system will require internet connection to work. This scenario is for
people who have their documents registered with their email. But if the user doesn’t have an
account he/she can’t send her documents through online.
The following scenario will be for users who are using their hard copy documents. Users will
present their document to a person that checks their document originality. The person checking
the document will scan the document. Then he/she will browse to NDVS website, upload the
document and also add additional information (i.e. Full name, Document Issuer name, date of
issue ) about the document and click the verify button. The system will use image processing to
verify the document originality on the repository to the document that is scanned. The system
will return three results. These results are; ORGINAL, NOT ORGINAL, DOESN’T EXIST. The
system returns ORGINAL response if the scanned document is the same with the document on
the repository. The system returns NOT ORIGINAL response; if the document is tampered or
changed in some kind of way. The system returns DOESN’T EXIST response; if the scanned
document doesn’t exists on the central repository.
This system will create an easy access for anyone who wants to verify the originality of a
document. And this will create an environment where people can trust a document so that the
details of a document will be believed without the slightest certainly of being forged.
There will be no place for forged documents and certificates, where by creating a situation that
can weed out documents that are tampered or forged. The system contacts both parties but also
uses a highly secured privacy system to protect the owner’s document from being used by
anyone without the approval of the document owner.
The system will have three main phases:
1. Will collect official data taken from institutes certify and store it,
2. Will let individuals pull their own certified data from the system,
3. Will send verified document which is certified by the institute and allowed by the
document owner.

Figure 1 Shows the graphical representation of the interation of users in the system. The
institutes send documents to users, and the users send their documents to companies. Companies
that want to verify document send documents to NDVS for verification. And the NDVS checks
with a template in the NDRS.
 Figure 1: proposed system

1.6 Feasibility Study

This feasibility study is the assessment of the practicality of the proposed system. The economic,
technical, Legal and operational feasibility of the proposed system will be discussed.

1.6.1 Technical feasibility

This section is the evaluation of the technical requirements of the project and the technical
resources available to meet the requirements.
Software: The softwares needed to develop the System are all Open source, which means the
softwares available for free.
Hardware: The hardware available to the developer’s team is enough to deliver a system of this
scope.
Personnel: Capable programmers (the developing team) are available for the delivery of the
proposed system.

1.6.2 Economic feasibility

There will be lots of positive economic benefits because of the NDVS system. The NDVS will
help reduce labor costs because the existing systems verify documents manually which requires
lots of labor.
Considering the reason mentioned above it will be reasonably less expensive than the existing
system in use.
Development cost: The system will depend on open source software’s and there will not be a
paid API or frameworks used for the development practices.
Labor Cost: the labor that the system needs is not fixed, so for now it can use the individuals
volunteering and including the team members are working as one.
Internet cost: high speed internet is needed in order to fetch and get what is verifying, so around
1mb internet minimal is needed, so it is affordable according to the internet
accesses we can get.
Server cost: for testing the system, we can use a minimal amount of server space, so in this case
the project will use a personal computers as a server.

1.6.3 Legal feasibility

The proposed system will comply with countries rules and regulations and proclamation. The
system will not contradict with the countries rules and regulations.

1.6.4 Operational feasibility

The system should be able to operate smoothly, so that the client and users could interact easily,
in order to achieve this the project needs support from companies to get involved in the system,
which is inexpensive because we believe there are companies willing to cooperate with this
project idea.
For the system the internet operation and the servers needed to operate this system is normal.
The system will be easy to use and is developed to be suitable even for users with minimal
computer skills. It will create a great interact-active and reliable system for users.

1.7. Methodology

Methodology is the systematic, theoretical analysis of the methods applied to a field of study. It
comprises the theoretical analysis of the body of methods and principles associated with a branch
of knowledge [6]. This will describe about the methods the researcher uses to find and gather
data to achieve the proposed system.

1.7.1 Data Gathering tools

Interview: An interview is a conversation where questions are asked and answers are given. In
common parlance, the word "interview" refers to a one-on-one conversation with one person
acting in the role of the interviewer and the other in the role of the interviewee. The interviewer
asks questions, the interviewee responds, with participants taking turns talking. [7] The project
team decided to use this method to find out what kind of problems some companies are facing
concerning document fraud.
Questionnaire : A questionnaire is a research instrument consisting of a series of questions and
other prompts for the purpose of gathering information from respondents.[8] Since it is difficult
to have an interview with a lot of people, our project decided in using this method to get a
conclusive idea about the problems the proposed system is going to solve.
Use cases : software and systems engineering, a use case is a list of actions or event steps,
typically defining the interactions between a role (known in the Unified Modeling Language as
an actor) and a system, to achieve a goal. [9] This will show the process of the proposed system
in way that makes it clear to understand the system easily.

1.7.2 Implementation Tools and methods employed

The project will be conducted using asp.net mvc framework for handling the logic of the
website, Microsoft sql server for the database, sematic ui frame work for front end view
development, compass and sass to compile css files for the front end development, angular js for
front end interactivity. Moq for testing website logics and karma for testing front end angular js
development. And the project team has also decided to use matlab, opencv and phash for image
processing.
The project team has decided to follow the following methods for the development of the
proposed system.
 Object oriented analysis approach
 Use Unit Testing to test code
 Use an MVC approach

1.8. Scope and limitations

1.8.1 Scope of the project

The NDVS system will provide a means by which users can verify the legitimacy of the hard
copy or softcopy of any sort of paper works, identifications and certificates online. The scope of
the system will mainly be focused on application of the system for institutes like colleges and
universities.
The system will also provide an online repository system by which all original documents can be
issued to recipients online and where the recipients can send the documents to organizations
requiring those documents.
The final product will be a web based system that will provide the above seen functions.

1.8.2 Limitation

The NDVS system will not provide face recognition or fingerprint identification to verify the
documents or rather to get the verified documents.

1.9 Project Management Plan

1.9.1 Time management plan

This Project Schedule provides estimated time that these tasks are aimed to be delivered.

Task Name Start Date Duration (Days)

1 Brainstorming Ideas 24-Oct 2016 2
2 Presentation & Title Approval 27-Oct 2016 6
3 Proposal Development 2-Nov 2016 13
4 Requirement elicitation 17-Nov 2016 30
5 Data Collection 12-Dec 2016 11
6 Design 18-Dec 2016 30
8 Implementation 15-Feb 2017 60
9 Testing 15-Apr 2017 30
10 Finalizing project 25-May 2017 30
 Table 1: Project Schedule

 Requirement elicitation: is the process of collecting the requirements of the system.

 Design: Design goals of the system are defined.
 Implementation: The stage where the system is developed. It involves interface design
and coding.
 Testing: is the process of analyzing the system so that it does what it is intended to do
and to find out defects in the system before it is put into use.

Gantt chart
Figure 2 is a Gantt chart that provides a graphical illustration of the project schedule.

Figure 2: Gantt chart

1.9.2 Quality management plan

The quality of the system will be defined by the fruitful implementation of the stated
requirements.
The quality standards set for the product are as follows:
 The NDVS will provide an easy to use document verification system
 The NDVS will speed up the process of document verification
 The NDVS would provide a way to store documents in a reliable way
  The NDVS would help minimize and control falsified documents from being used
The quality of the product will be measured and the deliverables should be consistent with the
above set standards.

1.9.3 Communication management plan

Communication among team members

The developing team communicates by having face to face meetings at least twice a week.
Through these meetings the status of the project is discussed and the workload is divided
amongst team members. The team also communicates using email, phone conversations and text
messaging.
Communication between advisor and team members
The team members meet face to face with the advisor on a weekly basis to get advises and to
discuss about the progress made and what will have to be done next. Other than face to face
meetings, communication is also made via email and phone.

Table 2 Communication table

Type of Method / Tool Frequency Information Participants

Communication /Schedule
Project Meetings Telephone When Sharing information,
needed project progress Team Members

Project Meetings Face to face When Sharing information,

needed project progress, division Team Members
of labor
Sharing of project data Email When All project documentation Team Members
needed and reports

1.10 Application of Results

The NDVS could be put in use by organizations that accept documents from individuals when
the individuals apply for different types of services or benefits. The system could be used by
organizations like embassies, banks, car rentals, hotels and telecom providers.
NDVS will also be put in use by companies looking to hire individuals as they will be able to
verify if the documents provided by individuals are legit or not.
NDVS could also be used by educational institutes for checking the transcripts and certificates
provided by people registering for programs.
NDVS could be useful for companies or institutes that issue official documents and will help the
companies or institutes in avoiding any form of falsification done in their name, which if not
tackled leads to their credibility being questioned.
In general, NDVS will be used by any type of service providing organization needing to verify
documents individuals present when applying for services.

1.11 Organization of the project

This documentation is structured into 5 chapters. The chapters are Introduction, Literature
review, System Requirements, System design and Conclusion and Recommendation.
In the first chapter which is introduction, the sections included are background to the study
problem area, motivation, statement of the problem, objective of the study, proposed system, and
scope of the study, methodology of the study and application of results of the study. The project
organization is also included in this chapter.
The second chapter discusses the literature review. The chapter contains a review of articles and
systems that are related to the study area which is document verification.
The third chapter discusses the system requirements. The chapter contains external interface
requirements, functional and non-functional requirements and use cases. The system
requirements are the descriptions of what the system should do.
The fourth chapter discusses the system design. The system design could be seen as the
application of the systems theory to product development. The chapter includes context diagram,
deployment diagrams, class Diagram and activity diagram.
The last chapter focuses on final conclusions and forwarded recommendations based on the
finding of the present study.
 Chapter 2: LITERATURE REVIEW

In order to get a clear understanding about Document Verification Systems, the developing team
has performed a review of existing articles and systems.
The reviewed articles give a brief description about the Coesys Document Verification, ARH and
DVS system in Australia.

2.1 Review

The Coesys Document Verification is a scalable distributed system that verifies identity
documents. The identity documents maybe passports, visas, ID cards and driver’s licenses [10].
Using the Coesys Document Verification system every document (hard copy or softcopy) can be
verified. Verifications on electronic and physical security features are also performed
automatically.
The system has been applicable in countries all over the world including the African country
Ghana.
The Coesys system works by checking the documents in question with the copies that they have
stored in their database. The first step when checking the authenticity of a document is scanning
the document. Next the data or information (country, type, version ...) from the document is
taken. Then the document is crosschecked with the copy of the document in the database. Finally
the detailed result is shown.
The Coesys database which stores copy of documents is administrated centrally. All updates
however are synchronized into all local repositories eradicating the need for regular manual
updates.
Coesys also has an Automated Border Control product that checks documents presented by
individuals entering a country. In Croatia, Coesys was chosen to upgrade the country’s border
control system. A mobile version of the Coesys Border Management system was used to run on
handheld mobile devices like biometric devices.
A high profile European bank has also put Coesys Document Verification system in use in their
branches. It was made so that each branch of the bank was connected with the Coesys document
verification repository.

The Document Verification Service (DVS) is an Australian based system, the system confirms
that the details of documents match the records held by the government authority that issued it
[11]. The DVS checks if the details exists or is valid and not expired or cancelled.
The Australian evidence of identity credentials that can be matched by DVS to mention a few
include birth certificates, change of name certificates, citizenship certificates, driver licenses,
ImmiCards, marriage certificates and more. The DVS can validate documents that have been
issued by the Australian Government and found in their database.
The DVS involves an authorized user, issuer, and DVS hub which is a technical router that
securely directs request between user and issuers [11].
When a person presents a document as evidence of their identity the DVS user first enters
information from the document. Information like name or date of birth from the document is
inserted into the system manually. From the DVS hub the extracted information is sent to the
supposed document issuer, here the matching process is done by the issuer. Next the document
issuer sends a computerized response via the DVS hub whether the document is authentic or not.
The validation of process of DVS only takes only seconds to perform, which compared to
manual systems is a great time saver. However the DVS doesn’t verify the authenticity of
physical documents or verify identities of clients presenting those documents.

AssureID: is a fast and accurate document authentication and identity verification software. This
verification software authenticates identity documents by using more than 50 different types of
forensic tests which are document specific. The verification process works by extracting
biometric and alphanumeric data from the documents.
To authenticate a document the first process is scanning the document. Next the data from the
document is taken and processed. After data extraction more than 50 forensic tests will be
performed on the credentials and the result will be displayed.
One of the tests performed is checking the details from the document against world watch lists
like Interpol, Office of Foreign Assets Control (OFAC) and Politically Exposed Persons (PEP).
AssureID uses a safe and secure cloud so that the data uploaded from the document is not hacked
or stolen.
By providing a fast and accurate system AssureID eliminates manual screening errors and speeds
up the document inspection.

ARH: ARH is a software that provides document verification for all identity document types
worldwide. The software provides a commercially accessible security checking platform.
Different type of identity documents like local ID cards, driver’s licenses, resident permits,
passports visa, address cards and more can be verified by this software.
The software examines scanned images of documents under different illumination thus the
application is able to weed out fake documents.
One of the features of the software is the optical character recognition (OCR) which is a software
that extracts text data from documents and then convers it to digital data. This data can be used
for executing fast and accurate registration. After the data is extracted an automatic verification
is executed which checks the details on the document will the template in their database.
The Software also has a pattern matching feature that checks the authenticity of documents by
comparing special security patterns with a background reference form a database that stores
patterns of attested genuine identity documents like ids and passports. This pattern matching can
be used for geometric signatures, visible patterns and even for patterns that are invisible to the
naked eye.

Direct Verify: Direct Verify is a website based in India. It is India’s largest online verification
network, which helps individuals authenticate documents online. This website is limited to users
needing documents verified in India.

2.2 Summary

The above seen Systems have created a reliable, accurate, scalable and distributed document
verification and have enabled a way to combat fraud.
The issue with document fraud is not to be taken lightly, the purpose of NDVS is to create a
Document Verification System that is suited for Ethiopia as the above seen systems have done
for their respective countries.
 Chapter 3: SYSTEM REQUIREMENTS

This chapter gives a thorough description of the National Document Verification System and
outlines the requirements for the system. It contains the External Interface requirements,
functional and non-functional requirements and use cases

3.1 General Description

3.1.2 Product Perspective

This system will be a web based system. This web Application will be used to obtain documents
directly from institutes and store those documents. Additionally the web application will be used
for uploading documents to be verified.
Since this project is data-centric, a database will be used. The database will be a repository
system which will receive and pile documents uploaded from any companies, institutes or
organizations.
The user will only access the database to get data, they will not be able to add or modify data. All
of this database communication will be over the internet.

3.1.3 Product Functions

By using the web application institutes will be able to upload documents of the recipients to the
document repository database.
Document recipients will be able to obtain their document from the document repository
database. The view will show the user’s personal document alongside with the profile of issuing
institutions.
Users will be able to scan and upload hardcopy of documents to check the originality. The result
will provide a reply about the document if it is either original or not.
The web based system will provide a functionality to manage the system and the document
information.

3.1.4 User Characteristics

There will be four types of users that will interact with the system.
 1. Institutes that issue the documents and upload it onto the system:
These users can only use the system to upload a document. This means that they will be
able to store data on the repository system with the required information.

2. Users that are the document recipients or individuals who own the documents:
These users can register and create an account. They can use this account to pull their
personal document from the repository system to their own profile. Also they can send
these documents to anybody requiring it, but they cannot edit or delete it.

3. Users that upload hardcopy document to use the system and verify that document
These users will be able to scan and upload documents they received from individuals or
companies and send it to our system to check the originality. The system will then use
image processing to check and send the result.
4. System Administrator
A system administrator is a user who will be given specific permission for managing and
controlling the system and managing company/institutes.

3.1.5 General Constraints

Since this system is a Web Application, internet connection is the main constraint. Because of
this, the application will not function if there is no internet connection.
Another constraint would have to be database capacity.

3.1.6. Assumptions and dependencies

The first assumption is that the system will be accessed on computers that have a good
performance, in order for the users to get the full advantage of the system. If the web browsers
used aren’t updated or up to standards there might be a chance the system will not work as
expected.

3.2 External Interface Requirements

3.2.1 User Interfaces

The system will be a web based application which means it will have a user interface (GUI) that
is going to be accessed with a browser.
The system should have a user-friendly interface, should be easy to navigate and should provide
backwards navigation.
When a user first opens the website he/she will see the home page. From there they will be
redirected to a page of their choice. It may be log in page, verify documents page or register page
(register as a document recipient, register as Company/Institute).
The system administrator should also be able to log in, by which he/she can administer the
system.
There are no special user interface requirements. Since the system is a web based application it
could be also accessible for people with disabilities.

3.2.2 Hardware Interfaces

The system has no hardware interface requirements.

3.2.3 Software Interfaces

The following are software’s that will be required for the system to be applicable.
Microsoft SQL server– 12.0.2269.0. : The system will use this database system since it is well
integrated with ASP.net mvc frame work.
ASP Net mvc frame work 5: the system will use this frame work for the manipulation of the
logic of the system. It is also well supported and integrated with visual studio.
Angular Js 1.5. : The system will use this java script frame work since it is well written and has
large community. It has a better testing environment and a strong model view biding.
Mat lab 9.1: The system will use this software for image processing. When there is a need for
comparison of images the system uses it to compare two images and determine if a scanned
document is the same as the original one.
Sass: The system must use sass to write a css file for the view of the website. Sass has a better
way to reuse css file and manage by modularizing css code.
Compass – 5.0: Is a frame work for sass that adds additional feature so the css files are going to
be compatible for different browsers. Since the system should be compatible for different
browsers the system must use this frame work to manage sass files.
Git- 2.5: The system is going to be built by a group of people and Git plays important role when
it comes to sharing code and controlling code version. So the system must Git for version control
and code sharing.

3.2.4 Communications Interfaces

The system will be web application and will use the HTTP protocol for communication over the
internet. Users of the system will communicate through internet connection. The system will be
compatible to different browsers and different operating systems.
Communication between different parts of the system will be handled by the underlying
operating systems.

3.3 Functional Requirements

This section defines all the functions of the system. It will show the proposed services and tasks
or what the system will do.

3.3.1 FR-1 Document Recipient Registration

Introduction
A document recipient shall be able to browse to the web site and register online. The document
recipient should provide email address and a password to register.
Inputs
The user will be required to input a Valid Email address and a password to register
Processing
Register user and add to the document recipients list.
Outputs
New Document Recipient is registered. Redirect to Profile page.
Error Handling
If the registration could not be completed because of error during interaction with DBMS, the
error should be displayed using a message box and the operation should be canceled. If the
details inputted by the user are not correct or aren’t in the correct format, an error message will
be displayed with a message box stating that the user should change the details.
3.3.2 FR-2 Company/Institute Registration
Introduction
Companies/Institutes shall be able to register on the web site by signing up on the system by
their representative. The company representative should provide an email, password and contact
of the company/institute. The registration will be successful after the system admin has activated
the account.
Inputs
The user will be required to input a valid Email address, a Password, Contact info of
company/institute for registration
Processing
Initiate the account activation process.
Outputs
Display a message that the user should stand by until the account has been activated.
Error Handling
If the registration could not be completed because of error during interaction with DBMS, the
error should be displayed using a message box and the operation should be canceled. If the
details inputted by the user are not correct or aren’t in the correct format, an error message will
be displayed with a message box stating that the user should change the details.

3.3.3 FR-3 System Admin Activate Company/Institute account

Introduction
The system admin shall be able to activate the account of companies. The admin should get a list
of registered companies on the system. The system admin can activate and deactivate companies
account. A company representative can only access an account if the admin activates the
company’s account. This system is useful to prevent fake company accounts. When a new
company is registered on the system the company information will be presented in a list form for
the system admin. Then the system admin will contact the company representative through email
or phone number and checks the legality of the company. When the system admin makes sure
that the company is legal institute, the system admin can activate the companies account.
Inputs
Company/Institute information
Processing
Check if the information provided is real and if the company/institute exists.
Outputs
Accept (Activate) or reject the Company/Institute account. Display message if account has been
created or not.
Error Handling
There should be no error

3.3.4 FR-4 Document Recipient log-in

Introduction
Document recipients shall be able to log- in. Given that they have registered, then they should be
able to login on the system.
Inputs
The user will be required to input their Email and password.
Processing
Process log in, check if email and password is correct or matches.
Outputs
Redirect to the user’s profile page if email and password are correct.
Error Handling
If the login could not be completed because of error during interaction with DBMS, the error
should be displayed using a message box and the operation should be canceled.

3.3.5 FR-5 Company/Institute log-in

Introduction
Companies or institutes shall be able to log- in. Given that a company representative has
registered on the system and the account has been activated by admin, the company
representative can log in to the system.
Inputs
The user will be required to input their Email and password.
Processing
Process log in, check if email and password is correct or matches.
Outputs
Display the Company (institute) profile page if email and password are correct.
Error Handling
If the login could not be completed because of error during interaction with DBMS, the error
should be displayed using a message box and the operation should be canceled.

3.3.6 FR-6 Company/Institute representatives shall be able to add document to the central
repository
Introduction
The company representatives shall be able add document of recipients to the central repository of
the system. Uploading a document requires the scanned image of the document, Institute name
that issued the document, date the document was given, document owner name. Information that
are optional to fill are Id of the document and email of the owner.
Inputs
The user should input Institute name that issued the document, date the document was given,
document owner name, scanned image of the document.
Processing
Process the adding of the documents to the central repository.
Outputs
Display message if the operation was successful or not.
Error Handling
If the operation could not be completed because of error during interaction with DBMS, the error
should be displayed using a message box and the operation should be canceled. If the details
inputted by the user are not correct or aren’t in the correct format, an error message will be
displayed with a message box stating that the user should change the details.

3.3.7 FR-7 Document Recipients shall be able to get their document online from
Companies/Institutes
Introduction
Document Recipients shall be able to get their documents from institutes addressed to them.
When the Document Recipients logs in to his/her account they will find documents that are
added to the central repository with their email. So the email acts as a link between the
Document Recipients and their documents. Documents that belong to them are going to be listed
on the user profile.
Inputs
Request from Document Recipients to see documents,
Processing
Display/Redirect to the documents received page
Outputs
Received documents page is displayed
Error Handling
If operation could not be completed because of error during interaction with DBMS, the error
should be displayed using a message box and the operation should be canceled.

3.3.8 FR-8 Document Recipients shall be able to send documents to other companies
Introduction
Document Recipients shall be able to send documents to companies that require them. After
users log in to their profile they will be able to send documents that are found on their profile to
other institutions or companies that require their document. Document Recipients will be able to
search for other companies before they send their documents to companies or institutes.
Inputs
Request from Document Recipients to send documents
Processing
Send documents to companies/institutes.
Outputs
If process was successful display the message “Documents sent successfully”, if it wasn’t
successful display the message “Documents couldn’t be sent”.
Error Handling
If the operation could not be completed because of error during interaction with DBMS, the error
should be displayed using a message box and the operation should be canceled.

3.3.9 FR-9 Companies shall be able receive documents from document recipients
Introduction
Companies shall be able to get documents that were sent from Document Recipients. Those
documents will have additional information. This information include the name of the Issuer
Company or institute, the date the document is issued, contact of the company or institute that
issued the document.
Inputs
Request from companies to see received documents.
Processing
Redirect the user to the received documents page.
Outputs
Redirect to the documents received page
Error Handling
There should be no error

3.3.10 FR-10 Users/ Companies shall be able to validate originality of document

Introduction
When a user submits a hardcopy document to a company that is register to the system, the
company will be able to validate the user’s document. To verify a document the user (company
representative) will scan the hardcopy and attach it to the form. Optional additional information
that could be parsed are ID and email of the document owner. After filling this information the
user (company representative) will click validate document button. And will have the result
whether the document is original or not. If the system fails to parse information that could
identify the document uniquely the system will ask the company to fill out those information
manually.
Inputs
In the form the owner’s name, issue date have to be filled in and the scanned document has to be
uploaded.
Processing
Check if the document is valid, by crosschecking with the copy in the document repository.
Outputs
The system will show the result of whether the document is original or not.
Error Handling
If the operation could not be completed because of error during interaction with DBMS, the error
should be displayed using a message box and the operation should be canceled. If the details
inputted by the user are not correct or aren’t in the correct format, an error message will be
displayed with a message box stating that the user should change the details.

3.4 Use Cases

Actors for the NDVS system:

1. Document recipient : Document recipients or individuals who own the documents
2. Company/Institute: Document issuing company
3. System Admin: a user who will be given specific permission for managing and
controlling the system
4. User: User that uploads hardcopy of document for verification
Figure 3 is the main use case diagram of the system, the actors are document recipient,
company/institute, system admin and user.

Figure 3: Use Case diagram for the Proposed System

3.4.1 Use case Number: FR-1/UC-1
Use Case Name: Register as a Document recipient
Actors: Document recipient
Use case Description: Document recipient’s online registration to the system.
Use case Flow: Document recipient online registration to the system.
1. The document recipient browses to NDVS web site
2. The document recipient Clicks button that says “Register as a Document
recipient”
3. The document recipient will be presented with a form to fill out the
required information
4. The document recipient fills out email address and password and click
the register button
5. The document recipient will be redirected to his/her profile page
6. Use case ends here

3.4.2 Use Case Number: FR-2/UC-2

Use case Name: Register as an institute
Actors: Company/Institute
Use Case Description: Company/Institute online registration to the system
Use Case Flow: Company/Institute online registration to the system
1. Company/Institute representative browse to NDVS web site
2. Company/Institute representative clicks a button that says “Register as a
company”
3. Company/Institute representative will be presented with a form to fill out
the required information
4. The Company/Institute representative fills out email address,
Company/Institute name, password, and phone number.
5. The Company/Institute representative will be redirected to a page that
describe the current status of its account. The page will describe that their
account will be activated after the system admin check if the company is
a legal company.

3.4.3 Use case Number: FR-3/UC-3

Use case name: Activate Company/Institute account
 Actors: System Admin
Use case Description: System Admin Activate Company account
Use case Flow: System Admin Activate Company account
1. The system admin wants to activate newly registered companies account.
2. The system admin clicks the “activate companies” link
3. The system displays companies that are not activated in a list form
4. The system admin clicks a company to be activated to see more
information
5. The system displays a view showing more information about the
company. Additional information that are going to be displayed by the
system are the company name, email address and phone number.
6. The system admin can contact the company representative and check the
legality of the company or the institute.
7. The system admin clicks the activate button to activate the company
profile.
8. The use case ends here

3.4.4 Use case Number: FR-4/UC-4

Use case name: login as a document recipient
Actors: Document recipient
Use case description: Document recipient can login to their account
Use case flow: Document recipient can login to their account
1. The document recipient browses to the NDVS
2. The document recipient enters email and password
3. The document recipient clicks login button
4. Use case ends here

3.4.5 Use case Number: FR-5/UC-5

Use case name: login as a Company/Institute
Actors: Company/Institute
Use case description: company representative login to the system
Use case flow: company representative login to the system
1. Company representative browse to NDVS
2. Company representative enters email and password
3. Company representative clicks login button
 4. Use case ends here

3.4.6 Use case number: FR-6/UC-6

User case name: Add document to the central repository
Actors: Company/Institute
Use case description: Company representatives add document to the central repository
Use case Flow:
1. The company representative wants to add a new document that was
issued by their institute
2. The company representative clicks add document link
3. The system displays a form to be filled in order to add document to the
central repository.
4. The company representative clicks the browse button to upload the
scanned document image and add it to the form.
5. The company representative adds the document owner name
6. The company representative adds their company name
7. The company representative adds the issuing date of the document
8. If the email of the document owner is provided, the company
representative adds the email address of the document to the input on the
form
9. If ID of the document is also available, the company representative will
also add the Id of the document.
10. The company representative clicks “Add document”
11. The system will show a confirmation message that the action was
successful
12. The use case ends here

3.4.7 Use case Number: FR-7/UC-7

Use case Name: Receive documents from Company/Institute
Actors: Document Recipient
Use case Description: Document recipient get their document online from institutes
Use case Flow:
1. Document recipient wants to see documents that are issued for him/her
2. Document recipient clicks “my documents” link
3. System displays list of documents that are issued for the document
recipient
4. Use case ends here
3.4.8 Use case Number: FR-8/UC-8
Use case Name: Send documents
Actors: Document recipient
Use case Description: Document recipient send document they get from other
companies. This documents can only be uploaded to the central repository by companies.
Document recipient cannot add documents to the central repository.
Use case Flow:
1. Document recipient wants to send documents through online to other
companies
2. User clicks “send documents to other companies”
3. System will display list of documents the Document recipient has
4. The document recipient selects documents they want to send to a
company or companies
5. The document recipient clicks next button
6. System displays a form to fill. In this form the document recipient should
fill the following.
a. Company name the document is going to be sent to
b. Description why they are sending this documents
7. The document recipient clicks “Send button”
8. Use case ends here

3.4.9 Use case Number: FR-9/UC-9

Use case Name: Receive documents from users
Actors: Company representative
Use case Description: When users send documents to companies online, companies can
see this documents on their profile.
Use case Flow:
1. Company representative wants to see documents sent to their company
2. Company representative clicks “received documents” link
3. System presents list of documents that are sent from different users
4. Use case ends here

3.4.10 Use case Number: FR-10/UC-10

Use case name: Verify Documents
 Actors: User
Use case description: The system also accommodate users who don’t use the online
system to send their document. When users have their document registered on the central
repository but still use their hard copy to send their document to companies or institutes;
the system can validate their document online with image processing.
Use case Flow:
1. User wants to validate a hard copy document
2. User clicks validate link
3. The system displays a form to fill
4. The User adds the scanned document to the form
5. The System identifies information that could identify the document uniquely
6. If the system can’t identify information that could identify the document, the
system will ask the user to fill out information about the document manually.
This information might include owner full name, Issue date of the document,
document issuer name i.e. Company name that issued the document
7. The User clicks “Validate document” button.
8. The System will process the scanned image of the document to the document
that is found in the central repository using image processing.
9. The system will return result of the validation. If the document is original, the
system will return a message that says “The Document is original”. If the
document has been changed in some kind of way the system will return a
message that says “The document is not original”.
10. Use case ends here.

3.5 Non-Functional Requirements

Non-functional requirements, as the name suggests, are requirements that are not directly
concerned with the specific services delivered by the system to its users [12]. The following are
the Non-Functional Requirements of the system.

3.5.1 Performance

 Users will be able to check the originality of a document in less than 10 minutes.
 Registered Companies/Institutes will be able to issue documents to recipients within
minutes.
 The local copy of the database will consume less than 20 MB of memory
3.5.2 Reliability

 The system should get the correct result about the originality of documents almost all of
the time.
 The system will not crash when invalid files are uploaded.

3.5.3 Availability

 The system will be available for the companies with a minimum 500kilobyte internet
connection.

3.5.4 Security

 User’s private information will be stored in a secured database of NDRS, which is

provided by ASP.NET framework security method.
 Data will only be inputted by the admin of the issuer through internet.
 Owners of the document will only access some information of their own which are
allowed by the issuer.
 The system will not be responsible for what the document issuer does on the document
information in the repository system.

3.5.5 Maintainability

 The system will be able to adapt to any changes and errors by updates
 Users can report any errors that the system fails to perform, get a result reply within a
week maximum, and get a solution on time depending on the problem.

3.5.6 Portability

Since the system will be web based, it will be portable as it can be accessed where ever there is
an internet connection.

3.6 Inverse requirements

The NDVS system will not provide face recognition or fingerprint identification to verify the
documents or rather to get the verified documents.

3.7 Design Constraints

The technical constraints of the project are as follows:
Programming language: The programming language that will be used mainly is C# and
ASP.Net Mvc frame work. This is because the Asp net frame work is extensible, manageable and
secure when compared to other frame works. It has also a debugging feature that is integrated
well with browsers. It lets the programmer to have a fine grain control over coding and
debugging.
Operating System or platform supported: Since the system is a web based system, it will
work on windows, linux, android, and iOS operating system.

The Business constraints of the project are as follows:

Team composition and make up: The team will be composed of four students that are going to
be fully committed on this project.
Software Licensing restriction or requirements: The project will be using a licensed visual
studio IDE and resharper for coding the main project functionality.

The hardware limitations of the project are as follows:

Project team individual computer requirements: The individual programmer in the team
needs a computer that has the following hardware specification.
At least 4 GB RAM
64 bit operating system
A processor speed of 2.40 GH minimum
Core i5 computers minimum

3.8 Logical Database Requirements

The project will use SQL server as a database. The data formats that database should support are
the storage of data like number and strings. Images are not going to be stored in the database. But
the reference of their location will be stored in the database. The database should have the
storage capability of 30GB for the first phase launch. The project will also retain data. The one
reason we want to retain a data is to recover business critical data in the event of site-wide data
loss. So the project will have data to be retain if a specific data is accessed once a within a year.
When a scanned document is accessed within a year it will be marked for retention.
The data integrity of the project will be classified as follows:
Physical Integrity: The physical integrity deals with challenges associated with correctly storing
and fetching data itself. The physical integrity often makes use of error detecting algorithms
known as error correcting codes. The project will use physical integrity test checks.
Logical Integrity: This type of integrity is concerned with the correctness or rationality of piece
of data, given a particular context. This includes topics such as referential integrity and entity
integrity. The challenges include software bugs, design flaws and human errors. The project will
insure Logical integrity through Check constraints, foreign key constraints, program assertions
and run time sanity checks.

3.9 Other Requirements

Training-related Requirements
The system will be straight forward and suitable even for users with minimal computer skills.
However users with no familiarity with the internet may be given training.
Packaging Requirements
The package will be a folder with code. That includes the content, resource files, configuration
files, JavaScript, css and so on.
Legal Requirements
The developing team will make sure to have all the processes in place so that the system is
complying with the law.

3.10 Change Management Process

If or when a request comes from the team members or the advisor to update the SRS document,
this idea will be raised and discussed in the weekly team meeting or through email. The change
will only happen if majority of the team members and the advisor agree. Upon request granted
the SRS document will be updated by the team members to imitate the changes made.
 Chapter 4: SYSTEM DESIGN

System design is the process of defining and developing the system to satisfy specified
requirements [13]. The purpose of the System Design is to translate the previously specified
requirements into a technical design that will be used in developing the system or software.

4.1 General Overview

This is the general overview of the application.

 Companies can add documents to the repository of Document Recipients.
 Document Recipients can get their documents online and send it to other companies too.
 Companies can verify scanned or hard copy documents with image processing.
High level information

Figure 4: High level Diagram

Figure 5 shows the symbols used in the context diagram and Data flow diagrams

Figure 5: Components of the context and Data flow diagrams

The context diagram is used to show the flow of data through the system. It shows what kind of
data will be input to and output from the system.
Figure 6 is the context diagram for the system which shows the data flow between the entities
and the system

Figure 6: Context Diagram

4.2 Development Methods & Contingencies

The development method the project will follow is object oriented system. Since the project will
depend on ASP.MVC frame work for the web site logic and functionality, the project will be
greatly inclined in using the frame works methods approach. The project will be separated in to
different major projects. The following are the project lists; The DOM (Domain object model),
WEB UI (contains the controllers and view of the website) and the Test project which will use
Moq for unit tests.
The project will use a repository and untiofwork for managing and controlling a generic
instantiation of classes. The generic instantiation class is more flexible and easy for future class
management. Dependency injection will be also used to instantiate classes creating more flexible
design.
Some of the contingencies that the project team considered was the image processing that takes
place when a company verifies a document that is scanned. The project team might use matlab or
phash based on unknown factors that might happen while implementing the project.
The other contingency plan the project team considering is, parsing information from a document
that could identify a document uniquely when trying to validate a document. If the project team
fails to accomplish this task the system will ask the company or the user to fill out information
that can be used to identify a document manually.

4.3 System Architecture

4.3.1 Subsystem decomposition

The subsystem decomposition will be shown using data flow diagrams.

Figure 7 shows the decomposition of the NDVS shown in the context diagram. 3 functions of the
system and the interaction between the external entities is depicted here.
 Figure 7: Data Flow Diagram Level 1

Figure 8 shows the level 1 decomposition of the document service or the data flow diagram level
2, it contains 2 subsystems.
 Figure 8: Subsystem Decomposition of Document service, Data Flow diagram level 2

4.3.2 Hardware/ Software Mapping

This section will show the run-time architecture of the system and it will also show the
configuration of the hardware elements and shows how the hardware is mapped to the node.
Components identified for the deployment diagram are the following. View, controller, model,
view model, repository, tests and database file.
Deployment environments included are server computer that runs on windows server 2012
standard edition, IIS 8, Microsoft SQL Server 2014 and Sql server manager for the database, user
and company computers that have a web browser installed on it.
The reason the project team decided on using sql server for database is because the web logic
and controller are going to be made with ASP.NET frame work using visual studio. Since they
are products from the same company (i.e. Microsoft), they are well integrated and works
seamlessly together.
The browsers could be installed on any operating system since the user can access the web
application on any system. User, company and the System Admin can access the application
through web site. Asp.net mvc program is used to do back end computation in retrieving data and
control the view of the project.
Figure 9 Shows the Deployment diagram

Figure 9: Deployment Diagram

4.4 Object Model

4.4.1 Class Diagrams

Class diagrams are used to show the classes in the system to be developed and the association
between them. Shown below are the classes, interfaces, and collaborations and their
relationships.
The class diagram has the different symbols; and their definition is as follows.
This diagram shows association between classes.
This symbol represents composition

1…* - This symbol represents one to many relationship

*…1 – This symbol represents many to one relationship
*…* - This symbol represents many to many relationship
0…*- This symbol represents many to many relationship

Figure 10 shows the class diagram of the system

Figure 10: Class Diagram
4.4.2 Sequence Diagram

A sequence diagram is an interaction diagram that shows how objects operate with one another
in what order. It is a constructed form of a message sequence chart. A sequence diagram shows
object interaction arranged in time sequence [14].
The following sequence diagrams show important functions listed on functional requirements of
the system. In the sequence diagram the arrows that are solid and pointing to the right are input
flow. While the dotted arrows that point to the left are outputs or results.

1. User Registration Sequence diagram

Figure 11 explains the user registration and the interaction between several entities of the
application.

Figure 11 Sequence diagram- User Registration

2. Company Registration Sequence diagram is the same as the user registration sequence
diagram.
Figure 12 explains company registration and interaction between several entities of the
application.
 Figure 12: Company Registration sequence diagram

3. System admin activating valid companies account (i.e. companies that are eligible to
issue a document with a legal license).
Figure 13 explains the System admin activating valid companies account (i.e. companies that are
eligible to issue a document with a legal license).

Figure 13: System Admin sequence diagram

4. User or Company login sequence diagram.
Figure 14 explains User or company login and interaction with entities.

Figure 14: Login Sequence Diagram

5. Company add document to the database sequence diagram.

Figure 15 shows the sequence of adding documents to the database. The company admin adds a
document then document is either added to the database or error is shown.

Figure 15: Add document sequence diagram

6. User gets documents from companies sequence diagram

Figure 16 shows the receive documents sequence and interaction with entities

Figure 16: receive documents Sequence diagram

7. User sends document to company sequence diagram

Figure 17 shows the sequence of sending documents to companies. First the user fills out a form
and requests data to be sent.

Figure 17: Send Document Sequence diagram

8. Companies can validate documents sequence diagrams

Figure 18 shows the document validation sequence in which the user adds document for
validation and the document is compared the original document in database.
 Figure 18: Verify document sequence diagram

4.5 Detailed Design

Class 1:

Table: User Attributes Description

Attribute Type Visibility Invariant
Id Bigint Public Id<> NOT NULL must contain a unique
Bigint
Email String Public Email <> NOT NULL
 Must contain @
 Must contain. (dot)
 Position of @ >1
 Position of (dot)>position of @ + 2
Position of (dot)+3<= total length of email
address and the total character of the Email is at
 least 8 characters
Email Boolean Public NULL it can be null, false or true
Confirmed
Password Hash String Public PassWordHash<> NULL Contains a
hash of the password
Phone Number String Public PhoneNumber<> NULL Must be at least
10 digits
User Name String Public UserName<> NULL Must be at least 6
digits

Table: User Operation

Operation Visibility Return Type Argument Precondition Post
Condition
GetNotification Public Notification UserId User Notification User
Should Exist Notification
Should not
Exist
GetRoles Public Role UsesrId User Role Should User Role
Exist Should Exist
GetUserClaims Public Claim UserId User Claim Should User Claim
Exist should exist

Class 2:

Table: User Manager Class Attributes

Attribute Type Visibility Invariant

User User Public User<> NOT NULL

Table: User Manager class Operations
Operation Visibility Return Type Argument Precondition Post
Condition
Login Public Void Username (string) User Name User Name
and password and password and password
(string) should exist should exists
Logout Public Void UserId Logged in user Logged in
should exist user should
not exist
Register Public Void UserName or UserName , User name,
Email (string) and email should email and
password (string) not exist password
should exits
Activate Public Boolean Hashlink UserAccount UserAccount
should not be should be
activated activated
Deactivate Public Boolean UserID User Account UserAccount
should be should be
activated deactivated

Class 3:

Table: Document Type attributes

Attribute Type Visibility Invariant

TypeId Int Public TypeId<> NOT NULL Must contain

a unique int number
Description String Public Description<> NOT NULL must
contain a description about the
Document Type

Class 4:
Table: Document Description attributes
Attribute Type Visibility Invariant

Id Bigint Public Id<> NOT NULL Must Contain a

unique
OwnerEmail String Public Email <> NOT NULL
 Must contain @
 Must contain. (dot)
 Position of @ >1
 Position of (dot)>position of @ + 2
Position of (dot)+3<= total length of email
address and the total character of the
Email is at least 8 characters
DocumentIssueDate Date Public DocumentIssueDate<>NOT NULL
Must contain the issue Date
OwnerName Date Public OwnerDate<>NOT NULL Should
contain the user name. Should not
contain special characters or
numbers
DocumentUniqueId String Public DocumentUniqueId<>NULL it can
contain special characters or
numbers

Table: Document Description operation

Operation Visibility Return Type Argument Precondition Post
Condition
GetDocumentType Public DocumentType - Document Document
Description description
Should should
Contain contain
Document Document
Type type
Class 5:

Table: Document Attributes

Attribute Type Visibility Invariant
Id Bigint Public Id<>NOT NUL should be a
unique number
IssuerId Bigint Public IssuerId<> NOT NULL should
reference an existing User I
IssuedForId Bigint Public IssuedForId<>NOT NULL
should reference an existing
User Id

Table: Document Operations

Operation Visibili Return Type Argume Precondition Post
ty nt Condition
GetDocumentDesc Public DocumentDescriptio Void DocumentDescri Document
ription n ption should Descreption
exists before should exists
retrieval after retrieval
GetDocumentSour Public DocumentSource Void DocuemtnSourc DocuemtnSou
ce e Should exists rce Should
before retrieval exists before
retrieval

Class 6:
Table: DocumentService Operations
Operation Visibility Return Type Argument Precondition Post Condition

GetDocument Public Document UserId Document Document Should

Should exist exist
AddDocument Public Boolean Document Document Document Should
should not exists
exist
EditDocument Public Boolean Document Document Document Should
Should Exists Exists

Class 7:

Table: Roles Attributes

Attribute Type Visibility Invariant

Id Int Public Id<> NOT NULL should be unique

Id
Description String Public Description<> NOT NULL

Name String Public Name<> NOT NULL should not

contain special characters or
numbers

Class 8:
Table: User Claim
Attribute Type Visibility Invariant

Id Bigint Public Id<> Not Null unique number

UserId Biginit Public UserId<>Not null unique number

and should represent an existing user
ID
ClaimType String Public ClaimType<>Not null should not
contain number or special characters
ClaimValue String Public ClaimValue<> Not Null, Should not
contain number or special character

Class 9:

Table: Profile Attribute

Attribute Type Visibility Invariant

UserId Bigint Public UserId<>NOT NULL should

be unique number
About String Public
FullName String Public FullName<>Not Null, should
not contain number or
special character
RegistrationDate Date Public RegistrationDate<>Not Null
BirthDate Date Public BirthDate<> Not Null
Gender String Public Gender<> Null, can contain
Male Female and null.

Table: Profile Operations

 Operation Visibility Return Type Argument Precondition Post Condition
GetProfileImag Public String UserId Profile Image Profile Image
e should exists should exists

Class 10:

Table: ImageProcessor Operations

Operation Visibility Return Type Argument Precondit Post Condition

ion
CompareImage Public Boolean Original Original Original
docuemtn Doument document
(Docuemnt) Should should exist
and sanned exists
Document(D
ocumet)
GetOriginalDocument Public Document DoumentDes Original Original
cription Documen Document
t Should should exists
exists
GetDocumentationInfor Public Documentatio DocumentId Documen Document
mation n (bigint) t Information
Information Informati Should exists.
on should
exists

Class 11:
Table: Notification Type Attribute
Attribute Type Visibility Invariant

Id Int Public Id<> NULL , should be a

unique int
Name String Public Name<>Not Null, should not
contain special character or
number
Description String Public Description<>Null, should
not contain special character
or number

Class 12:

Table: Notification Attribute

Attribute Type Visibility Invariant
Id Bigint Public Id<>Not NULL, Should be
unique bigint
Status String Public Status<>Not NULL, Can be
READ,UNREAD
NotifierId Bigint Public NotifierId<>Not Null,
Should be an existing User
Id

Class 13:
Table: Message attribute

Attribute Type Visibility Invariant

Id long Public Id<>Not NULL, Should be
unique long
SenderId long Public SenderId<>Not NULL,
Should be unique long
RecievedId long Public RecieveId<>Not NULL,
Should be unique long
Description String Public Description<> NOT NULL,
should be String

Table: Message operation

Operation Visibility Return Type Argument Precondition Post
Condition
GetDocument Public Document UserId Document Document
Should exist Should
exist

4.6 Activity Diagram

The activity diagram shows the activities involved in the NDVS system and the sequencing of
those activities. The arrows in the activity diagram show the sequential dependencies.
Figure 19 shows the activities in the system and how they are coordinated
Figure 19: Activity Diagram
 Chapter 5: CONCLUSION AND RECOMMENDATION

5.1 Conclusion

Currently in Ethiopia because the verification systems are mostly manual it has enabled fake
documents to pass through as authentic documents. In addition because of the systems being
manual it has resulted in a time consuming, inconvenient, labor demanding and unreliable
verification process.
Since the proposed system will be automated it will create an accurate, convenient and reliable
document verification system so that forged documents can be identified easily. The developing
team strongly believes that the proposed system, if put in use will help reduce the impact of
document forgery by a large margin.
This finalized documentation is the first stage of the project. The project team is working on
developing a national document verification system that provides all the system requirements
and system design mentioned in the above section 3 and 4 respectively for the following
semester.

5.2 Recommendation

Considering the time limitation, we have narrowed the depth of the project. The system that will
be developed by the project team is mainly based on the institutions and educational bureaus but
there are areas that the project team believes are valuable even though it has not been covered or
implemented by the project.
For future study or project, the project team recommends that any document issued by a
governmental or non-governmental institutes or even any organization be stored in the repository
system. Then giving the people their own secured number or ID and code to access from that
repository system rather than going to offices in person. This will help a great deal in eradicating
forgery and a part of corruption done on document falsifying.
Furthermore, the project team would like to state that additional findings and recommendations
will be stated in the final paper in the following semester; that is the implementation phase.
 REFERENCES

[1] http://www.legalmatch.com/law-library/article/falsifying-documents.html Accessed date

November 6, 2016.
[2] Methods of document recognition and authentication article
http://www.wes.org/ca/acadamic/docauth.pdf
[3] “A GOOD PRACTICE GUIDE ON PRE-EMPLOYEMENT SCREENING” Published by
Center for the Protection of National Infrastructure (September, 2011), Accessed date November
5, 2016.
[4] http://www.mfa.gov.et/web/guest/document-authentication, Accessed date November 2,
2016.
[5] https://en.wikipedia.org/wiki/Fraud, Accessed date November 5, 2016
[6] https://en.wikipedia.org/wiki/Methodology, Accessed date November 9, 2016
[7] https://en.wikipedia.org/wiki/Interview, Accessed date November 10, 2016
[8] https://en.wikipedia.org/wiki/Questionnaire, Accessed date November 9, 2016
[9] https://en.wikipedia.org/wiki/Use_case, Accessed date November 7, 2016
[10] http://www.gemalto.com/govt/coesys, Accessed date November 8, 2016
[11] http://www.dvs.gov.au/How-the-DVS-works/Pages/default.aspx, Accessed date November
3, 2016
[12] Software Engineering (9th Edition) by Ian Sommerville, 1996 Pearson Education, Inc.,
publishing as Addison-Wesley.
[13] https://en.wikipedia.org/wiki/System_design, Accessed date December 16, 2016.
[14] https://en.wikipedia.org/wiki/Sequence_diagram, Accessed date December 25, 2016.
 APPENDIX A: Project Cost

The following table is the cost breakdown structure for the project from project initiation to
implementation.

Table 3: Cost Breakdown

No Item Cost (ETB)

1 Visual Studio 2015 Enterprise Edition 11,976.45

2 Microsoft Office Professional 2016 10,731.84
3 matlab 1,080.00
4 Phash Free
5 Server PC 22,668.70
6 Windows Server 2012 Standard Edition 29,016.85
7 Printing 500.00
8 Internet 1,500.00
Total Cost 77,473.84
 APPENDIX B: Glossary

Actor
A coherent set of roles that users of use cases play when interacting with the use cases.
Asp.net
An open source server-side web application framework designed for web development.
Gantt chart
An alternate form bar chart.
Image Processing
Image Processing is a processing of images using mathematical operations by using any form of
signal processing for which the input is an image.
MVC
Model View Controller is a software design pattern for implementing user interfaces on
computers.
Use case diagram
A diagram that shows a set of use cases and actors and their relationships; use case diagrams
address the static use case view of a system.