Final Project Matrimony Edited-Nu

ARBAMINCH UNIVERSITY
ARBAMINCH INSTITUTE OF TECHNOLOGY (AMiT)
“Ethio-Matrimony”
GROUP MEMBER’S NAME AND ID NO
1. ASSEFA SENBATO RAMIT/1320/05

2. HABTEMU DESTA RAMIT/1411/05
3. ABDULKERIM MOHAMMED RAMIT/1280/05
4. NATHINAEL MESFIN RAMIT/1505/05
5. DAWIT BELETE RAMIT/1361/05
Advisor: Mr. Sajil.Surabhi Examiner: …………………
A Senior Project Report
Submitted to Department of Computer Science and IT, Arbaminch Institute of Technology,

AMIT, and Arbaminch University in partial fulfillment for the requirement of the Degree of
Bachelor Science in Computer Science and IT.
Arbaminch, Ethiopia
31st May 2016
Ethio-Matrimony 2015/16
Arba Minch University
Arba Minch Institute of Technology(AMiT)
Approval Sheet
---------------------------------------------------------------------------------------------------
-
This is to certify that the senior project titled “Ethio-Matrimony”, submitted by

Assefa Senbato(Ramit/1320/05)
Habtemu Desta (Ramit/1411/05)
Abdulkerim Mohammed (Ramit/1280/05)
Nathinael Mesfin (Ramit//1505/05)
Dawit Belete (Ramit/1361/05)
To the department of Computer Science and Information Technology, Arbaminch for the partial
fulfillment of the requirement of the Degree of Bachelor Science in Computer Science and IT, is
a bona fide record of the project done by them under my supervision. The contents of this
document in full, or in parts, have not been submitted to any other institute or university for the
award of any degree or diploma.
Mr. Sajil.Surabhi
(Advisor)
Date: 31st May 2016

Arbaminch
Final Year Project documentation Page ii

I. Acknowledgement
First of all we would like to express our internal and endless thanks to Almighty God who
helped in every aspects of our life and made us to being graduating student in this academic year.
Next we would like to express our deepest gratitude to Mr. Sajil, whose encouragement,
guidance and support from the initial to this level enabled us to develop an understanding of the
project and finishing our first phase on time. We also like to thank Sosit Gulicha match making
Agency for their helps to share some idea and existing system form. Lastly, we offer our regards
and blessings to all of those who supported us in any respect including CS & IT department
Head and staffs during this project.
Final Year Project documentation Page iii

II. Abstract
Matrimonial web sites or marriage websites are used as an alternative to the

traditional marriage broker to find a perfect life partner. The main aim of the Matrimonial Project
is to provide a relation between Agents and Profile looking users. The marriage agents will post
their user profiles with photos and the end user or individual user will also post his profile with
Photo to get the suitable matches. The proposed web application is providing a unique
functionality to save their search results as per their criteria in the webpage. In this project,
profiles can be exchanged by the user’s interests and the contact information will be displayed
after the mutual acceptance from both sides of the users.
Many people in our country have different interest or dynamical feeling regarding their marriage.
Depending on their interest, it may not be possible to get a full satisfied life partner by using
manual activities like the agents (broker) or media. We believe our “ Ethio-Matrimony ”, a web
based application will be a solution towards this problem at least for certain people in our
country. We hope that, this will be useful for all in the near future of Ethiopia, since it is cheap
and time saving effort.
Final Year Project documentation Page iv

Table of Content
Contents
I. Acknowledgement..............................................................................................................................iii
II. Abstract...............................................................................................................................................iv
List of Figures.............................................................................................................................................vii
List of Tables..............................................................................................................................................ix
Chapter One: Introduction...........................................................................................................................1
1. Introduction.........................................................................................................................................1
1.1 Background of Arbaminch University (AMU)................................................................................1
1.1.1 Mission of AMIT.....................................................................................................................1
1.1.2 Vision of AMIT.......................................................................................................................1
1.2 Background of the Project (Background of Study)..........................................................................2
1.3 Team Composition..........................................................................................................................2
1.4 Statement of the Problem.................................................................................................................3
1.5 Objective of the Project...................................................................................................................3
1.5.1 General Objective....................................................................................................................3
1.5.2 Specific Objective....................................................................................................................3
1.6 Feasibility Analysis.........................................................................................................................4
1.6.1 Technical Feasibility................................................................................................................4
1.6.2 Operational Feasibility.............................................................................................................4
1.6.3 Behavioral/Social Feasibility...................................................................................................4
1.6.4 Schedule Feasibility.....................................................................................................................4
1.7 Scope and Significance of the Project..............................................................................................5
1.8 Target Beneficiaries of the System..................................................................................................8
1.9 Methodology for the Project............................................................................................................8
1.9.1 Data Sources............................................................................................................................8
1.9.2 Fact Finding.............................................................................................................................8
1.9.2.1 Interview..............................................................................................................................8
1.9.2.2 Surfing the Web....................................................................................................................8
1.9.2.3 Document analysis...............................................................................................................8
Final Year Project documentation Page v

1.9.3 Analysis and Design Approach................................................................................................9

1.9.4 Development Tools......................................................................................................................9
1.9.5 Testing procedure..................................................................................................................10
1.9.6 Implementation......................................................................................................................11
1.9.7 Limitation of the Project............................................................................................................11
1.9.8 Risk, Assumption and Constraint...........................................................................................11
Chapter Two: Introduction of Existing System.........................................................................................12
2.1 Introduction of Existing System....................................................................................................12
2.2 Players in the Existing System.......................................................................................................12
2.3 Major functions/activities in the existing system like inputs, processes & outputs........................13
2.4 Business rules................................................................................................................................14
2.5 Report generated in the existing system.........................................................................................14
2.6 Forms and other documents of the existing systems (Gulicha, 2004)............................................15
2.7 Bottlenecks of the existing system.................................................................................................15
2.7.1 Performance...........................................................................................................................15
2.7.2 Input and Output....................................................................................................................15
2.7.3 Security and Controls.............................................................................................................16
2.7.4 Efficiency..............................................................................................................................16
2.8 Practices to be preserved................................................................................................................16
2.9 Proposed solution for the problems of the existing system............................................................16
2.10 Requirements of the Proposed System...........................................................................................17
2.10.1 Functional requirements.........................................................................................................17
2.10.2 Nonfunctional requirements...................................................................................................19
Chapter Three: System Analysis................................................................................................................20
3.1 Introduction...................................................................................................................................20
3.2 System Requirement Specifications (SRS)....................................................................................20
3.2.1 Use case Diagram..................................................................................................................21
3.2.2 Use case documentation (for each use case identified)..........................................................22
3.2.3 Sequence diagram..................................................................................................................34
3.2.4 Activity Diagram.......................................................................................................................45
3.2.5 Analysis level class diagram (conceptual modeling)..............................................................55
Final Year Project documentation Page vi

3.2.6 User Interface Prototyping.....................................................................................................56

3.2.7 Supplementary specifications................................................................................................57
Chapter Four: System Design....................................................................................................................58
4.1 Introduction...................................................................................................................................58
4.2 Class Type Architecture.................................................................................................................58
4.3 class modeling...............................................................................................................................60
4.4 State chart modeling......................................................................................................................61
4.5 Collaboration modeling.................................................................................................................64
4.6 Component Modeling....................................................................................................................66
4.7 Deployment modeling...................................................................................................................67
4.8 Persistence modeling.....................................................................................................................68
4.9 User Interface design.....................................................................................................................69
Chapter Five: Implementation & Testing...................................................................................................71
5.1 Introduction...................................................................................................................................71
5.2 Final Testing of the system............................................................................................................71
5.2.1 Unit testing:...........................................................................................................................71
5.2.2 Integrated tasting...................................................................................................................71
5.2.3 Black box testing...................................................................................................................71
5.2.4 White box testing...................................................................................................................71
5.2.5 Functional (black box testing) and system testing..................................................................72
5.3 Hardware software acquisitions.....................................................................................................88
5.4 User manual preparation................................................................................................................88
5.5 Training.........................................................................................................................................88
5.6 Installation Process........................................................................................................................89
5.7 Start-up strategy.............................................................................................................................89
Chapter 6: Conclusions and Recommendations.........................................................................................90
6.1 Conclusions...................................................................................................................................90
6.2 Recommandations.........................................................................................................................91
References.................................................................................................................................................92
Works Cited...............................................................................................................................................92
Final Year Project documentation Page vii

List of Figures
Figure 1 form of existing system...................................................................................................15
Figure 2 Use case Diagram............................................................................................................21
Figure 3 Description of Login Sequence Diagram.......................................................................34
Figure 4 Description of Registration Sequence Diagram.............................................................35
Figure 5 Description of See matches Sequence Diagram.............................................................36
Figure 6 Description of See contact profiles Sequence Diagram................................................37
Figure 7 Description of Edit profile Sequence Diagram.............................................................38
Figure 8 Description of Payment option Sequence Diagram......................................................39
Figure 9 Description of Generate report Sequence Diagram........................................................40
Figure 10 Description of Manage user and system Sequence Diagram.......................................41
Figure 11 Description of Searching Sequence Diagram...............................................................42
Figure 12 Description of Send/Receive message Sequence Diagram..........................................43
Figure 13 Description of Notification Sequence Diagram..........................................................44
Figure 14 Description of Login Activity Diagram.......................................................................45
Figure 15 Description of Registration Activity Diagram..............................................................47
Figure 16 Description of See matches Activity Diagram..............................................................48
Figure 17 Description of See contact profile Activity Diagram....................................................49
Figure 18 Description of Edit profile Activity Diagram...............................................................50
Figure 19 Description of Payment option Activity Diagram.........................................................51
Figure 20 Description of Generate report Activity Diagram.........................................................52
Figure 21 Description of Manage user and system Activity Diagram..........................................53
Figure 22 Description of Searching Activity Diagram..................................................................54
Figure 23 Description of Notification Activity Diagram..............................................................55
Figure 24 Description of Class Diagram.......................................................................................56
Figure 25 Description of Prototype Diagram................................................................................57
Figure 26 Class Type architecture...............................................................................................59
Figure 27 Class Modeling..............................................................................................................61
Figure 28 State chart diagram for login.........................................................................................62
Figure 29 State chart diagram for register..................................................................................62
Figure 30 State chart diagram for see matches.............................................................................63
Figure 31 State chart diagram for payment option........................................................................63
Figure 32 State chart diagram for manage user and system.........................................................64
Figure 33 State chart diagram for update profile..........................................................................64
Figure 34 Collaboration diagram for login...................................................................................65
Figure 35 collaboration diagram for registration...........................................................................65
Figure 36 Collaboration diagram for search user........................................................................66
Figure 37 Component diagram.....................................................................................................67
Figure 38 Deployment diagram....................................................................................................68
Figure 39 persistent diagram........................................................................................................69
Final Year Project documentation Page viii

Figure 40 Home page by English................................................................................................70

Figure 41 User login page.............................................................................................................70
Figure 42 Admin login page..........................................................................................................71
Figure 43 Amharic home page.....................................................................................................71
List of Tables
Table 1 Team Composition............................................................................................................2

Table 2 Tasks and Schedule...........................................................................................................5
Table 3 Description of Login Use case..........................................................................................22
Table 4 Description of Registration Use case................................................................................23
Table 5 Description of see matches Use case................................................................................24
Table 6 Description of see contact profile Use case......................................................................25
Table 7 Description of Edit profile Use case.................................................................................26
Table 8 Description of Payment option Use case..........................................................................27
Table 9 Description of Generate report Use case..........................................................................28
Table 10 Description of Manage user and system Use case..........................................................29
Table 11 Description of Searching Use case.................................................................................30
Table 12 Description of Send/Receive Use case...........................................................................31
Table 13 Description of Notification Use case..............................................................................32
Table 14 Description of Send warning Use case...........................................................................33
Table 15 class type modeling........................................................................................................60
Table 16 Test case – 01.................................................................................................................74
Table 17 Test for registration.......................................................................................................78
Table 18 Taste case 03...................................................................................................................82
Table 19 Test case 04....................................................................................................................87
Final Year Project documentation Page ix

Chapter One: Introduction
1. Introduction
The Matrimonial Web Based Application is to provide Grooms and Brides with excellent
matchmaking experience by exploring the opportunity and resources to meet true potential
partner. Keeping our objective in mind, we will create a world renowned online matchmaking
services that will touch the souls of millions of people in Ethiopia. This application make
comfortable and effective search for life partners based on their interest without any agent (third
person between grooms and brides).Users can register in our site; they are able to upload their
profile with photographs onto a searchable database maintained by the website. Those users
looking to find their partner can search the database with customized searches that typically
include nationality, age, gender, religion, caste, geographic location, height, weight, color of
skin, color of eyes etc.. Once they become a paid member of our site, users will get the
permission to chat with their interested match so that they can communicate to know each other
deeply.
1.1Background of Arbaminch University[CITATION AMU \l 1033 ]

Arba Minch University (AMU) is one of the well-established universities found in the Southern
Nations, Nationalities and People's Region (SNNPR). It is located at Arba Minch town, 500 km
south of Addis Ababa the capital city of Ethiopia. The main campus of the university is situated
at the eastern foot of Gamo mountain ranges and adjacent to the vast low land stretching towards
the Lake Abaya and Lake Chamo which form part of the East African Rift Valley.
1.1.1 Mission of AMIT

Arba Minch University has a mission of offering relevant and quality education and training;
conducting demand driven research and rendering accessible community services.
1.1.2 Vision of AMIT

Arba Minch University aspires to be a leading University in Ethiopia, a center of excellence in
the field of water resources in Africa and competitive in the world by 2020.
Final Year Project documentation Page 1

1.2 Background of the Project (Background of Study)
Matrimonial Web sites are changing the rules of how relationships are formed and maintained in
communities all over the world. Online matrimonial services can fill the gap left by the absence
of social networks in societies transitioning to urban and modern culture. The use of online
matrimonial services can be providing an interesting illustration of technology in society. The
use of online services will dilute the societal norms about socializing among opposite sexes but
at the same time preserved traditional notions of compatibility by providing easy access to
information about religion and community.
In Ethiopia, people uses different mechanism for finding match mates for marriage through
media (FM Radio program), through agents (dellala), uses some dating sites which are not
popular. We just wanted to replace these traditional methods by introducing a new matrimonial
web site to Ethiopian citizens. We hope that “Ethio-Matrimonial” web based application will be
a new and useful site in our country for finding the perfect partner. The “Ethio-Matrimonial”
sites contains information like personal details, physical attributes, education and occupation,
habits, family profile and more about grooms and bides.
1.3Team Composition
The technical team of this project comprises 5 computer science B.Sc. undergraduate students.
# Name ID No Work Division Email-ID
1 Assefa RAMIT/1320/05 Project Leader, Ayese96@gmail.com
Senbato Designer, Programmer
2 Nathinael RAMIT/1505/05 Asst. Project leader, Nathinaelmesfi@gmail.com
Mesfin Designer, Programmer
3 Abdulkerim RAMIT/1280/05 System Designer & Kermo.mo@gmail.com
Mohammed Analyst
4 Habtemu RAMIT/1411/05 System Analyst & Habte.desta@yahoo.com
Desta Tester
5 Dawit Belete RAMIT/1361/05 System Designer & Dawit.belete@yahoo.com
Tester
Table 1 Team Composition

1.4Statement of the Problem
The existing mechanism of marriage in our country is not satisfactory according to the
communication between grooms and brides through some media (like FM Radio), agents and
through some dating sites like www.lovehabibi.com. There are many problems according to
above mechanism: the groom and bride cannot express their real choice and interest through
agents and medias, as they cannot present the full information. Also, agents may take more
money to fix a marriage. There is always missing a chance to chat between the groom and bride
before the marriage. There is no comfortable communication like chatting or calling via systems.
Also, they may not get enough details about the partner’s surroundings and their background
details through media or agents.
1.5 Objective of the Project
1.5.1 General Objective

The general objective of this project should be developing localized “Ethio-Matrimony” web
based application.
1.5.2 Specific Objective

To achieve the above mentioned general objective, the project has the following specific
objectives:
 To provide a platform to enter the world of hundreds or may be thousands of prospective
partners. One just has to set a few filters as to what one is seeking in a partner.
 To facilitate matchmaking business by applying the features to talk to a person and
staying in touch also understand a person’s culture and family values. Also features to
upload the profile pictures which speak a lot about a person.
 To enable the users to deal with secure payment to access the system.
 Ensuring personal profiles are managed securely in a powerful database.
 This application also provide a search utilities which helps those users who have a certain
criteria of qualities in mind to make online matrimonial easier.
 provide the simulation bank system

1.6 Feasibility Analysis
Feasibility study is a process of we check possibilities of system development. It is a method to
check various different requirements and availability of financial and technical resources.
1.6.1 Technical Feasibility
The proposed system can be technically feasible because the technical resources needed to
develop, install and to operate is available in the present infrastructure and also the tools we will
be used to develop our is technically support existing resource such as hypertext markup
language (HTML) for client side scripting, Java Script for validation, MySQL for database
server, Apache for web server, hypertext pre-processor (PHP) for server side scripting, and
Macromedia Dream weaver, PHP Designer, and Notepad++ for writing source codes. So, the
proposed system can be technically feasible.
1.6.2 Operational Feasibility
Ethio-Matrimony Application is Operational feasible because of the application can be support
local language like Amharic, Afan Oromo and other which familiar with local users and also
English, In addition of this Ethio-Matrimony site cannot need more knowledge about system and
other digital devices because a system have an interactive interface that can make user easy to
use and familiar with a system.
1.6.3 Behavioral/Social Feasibility
Ethio-Matrimony web application provides marriage website, which will meet the need of bride
and groom according to their preferences and give effective services for society in Ethiopian.
Getting an online presence matters a lot for any business today. Online matrimonial services can
fill the gap left by the absence of social networks in societies and so can termed as socially
feasible.
1.6.4 Schedule Feasibility
The proposed system can be implemented in an acceptable timeframe given below. Project
coordinator is also responsible for monitoring & controlling the project development based on
the schedule shown below.

Gantt Chart - Project Schedule
S.N Phases 1st quarter 2nd 3rd 4th 5th 6th
o quarter quarter quarter quarter quarter
10th Dec- 15th
15th May- 25th

18th Mar–25th Apr
28th Apr- 15th May
June
17th Dec-10th Mar
Dec
May
1 Project Proposal
2 Requirement
Analysis
3 Design
4 Implementation
5 Installation &
Testing
6 Project Closure
Table 2 Tasks and Schedule
Start Time duration End
1.7 Scope and Significance of the Project

The scope of our project is a Matrimonial website development which will provide a platform to
a lot of Brides or Grooms for finding perfect match. Our project contains the following scope:-
For New User:
 Member registration (paid or free).
 Browse categories that are sorted by region, community, religion.
 Advanced search with additional parameters. (Based on educational qualification etc..
 Listing of limited information for non-members and unrestricted access to the complete
profile for members.
 Featured profile listings on homepage along with thumbnail images.
 Static information pages. [Some advertisements related to site]
 Profile View Counts.
For Registered Member:

 Membership Information.
 Manage membership account information.
 Subscription details.
 Edit own profile.
 Upload Photos (multiple).
 Protect Photos.
 View Details of Members.
 Shortlist Matches.
 Recent Profiles Module on Homepage.
Search:
 Search by Profile ID
 Search by City/ State
 Search by Religion/Community
 Occupation Search
 Education Search
Contact Profiles:
 Show or Express Interest.
 List of members whom the user has accepted.
 List of members who have accepted the user.
 List of members who have contacted the user.
 List of members whom the user has contacted.
 Listing of all incoming messages.
 Listing of all sent messages.
 Forward the profile to a friend.
 Send Personalized Messages.
Payment Features:
 Payment Entry Form
 Payment Invoices& Receipts
 Consolidated Accounts Summary
 Renewal for Paid Members.
Reporting Module:

 Inactive Members Report.
 Free/Active Members Report
 Paid Members Report.
 View Reports of users by City / Gender / Country
 Edit Member Details
Staff Administration:
 Add/Edit/Delete Staff Users
 Individual Staff Login
 Restricted Admin Features for Staff
Mailing features:
 Registration confirmation message.
 Membership Expiry Reminder Notices.
 Users sending personal message.
 Notify new users.
Requirements to run the application:
 Domain Name.
 Hosting Space –Configure a domain name server.
 MYSQL Database – Configure a database server.
In addition to the above mentioned scopes, we will try to provide following capabilities:-
 Chat box.
 Contact us module
 Success story module
 Feedback module
 Some common language in Ethiopia that helps to use the different features without any
difficulty like Amharic and Oromic.
Significance of our project:
 To join bride and grooms from different area through system without physical availability
in order to have a good understanding among them.
 Support some common language of our country to avoid language problem through
society.
 To decrease mismatch between groom and bride in their life.

 To increase technologically access in the country rather than society depend on only in
tradition way.
 Changing the wrong ideologies about marriage in the societies
 Making the process of marriage simple and effective.
1.8 Target Beneficiaries of the System

There are different bodies that can be benefited from the proposed matrimony website such as:
 Ethiopian nationalities all over the world
 Website developed team, though it’s a business too.
1.9 Methodology for the Project

The methodology we use to develop the system is Object-Oriented methodology.
1.9.1 Data Sources
For the development of the proposed system the team used different data sources such as books,
internet, society, brochure and other sources as required.
1.9.2 Fact Finding

To get a precise data from the society the team has used the following fact finding techniques.
Those are: -
1.9.2.1 Interview – We have used this fact finding techniques to get basic information and
background information about the existing system in our country relate to marriage
.Example, We try to ask Sosit Gulicha match making Agency to understand some
business rule the organization use and form available in existing systems.
1.9.2.2 Surfing the Web – We have used surfing the web because of we want to make our
system popular, comfort and compute with other developed site. Example we surfed the
web for other information such as the working of the other similar sites which are popular
in other countries, especially in India.
1.9.2.3 Document analysis –We have used document analysis to share some concept from
document before done and to increase understandability for each section we will do in
our project. Example we have used previous document ‘Local mailing system’.

1.9.3 Analysis and Design Approach
Among the different methodologies available we are using object oriented methodology for the
analysis and design of our system. Object oriented methodology enables us to represent complex
relations among different objects and represent data and process with consistent notation
throughout the system. Also it greatly improves the communication among customers, analyzers,
designers and programmers. It also allows the reusability of the code which will help to enhance
the project in the future.
1.9.4 Development Tools
Activities Tools/Programs
Client Side Coding HTML,CSS.
Client Side Scripting JavaScript
Platform MS Windows
Database Server MySQL
Web Server Apache
UML Diagram Edraw Max
Server-Side Scripting PHP
Browsers Chrome, Mozilla Firefox
Editors, Tools PHP Designer, Notepad++
Documentation MS Word ,MS Excel
User Training MS Power Point
Table 1.2 Development Tools
We have used above development tools because of our team are more familiar with above such
as hypertext markup language (HTML) for client side scripting, Java Script for validation,
MySQL for database server, Apache for web server, hypertext pre-processor (PHP) for server
side scripting, and Macromedia Dream weaver, PHP Designer, and Notepad++ for writing
source codes among the language like Java and other we have study in our department .The
main reasons we have chosen above is we have study well and understood well during our
lectures and done some project with above tools.
1.9.5 Testing procedure

Before directly deploying this system the team will perform different types of testing procedures
for its functionality and acceptance.

Unit testing: - First we will tests each unit at each system. So, if a problem is encountered it will
immediately maintain at which the problem is occurred.
Black box testing: - the project can be viewed only in terms of its input, output and transfer
characteristics without any knowledge of its internal workings. These means we will use one
user who already has an account then the user will see his/her account detail and have chance to
update its profile.
The team will use this testing technique for the following reasons
 More effective on larger units of code.

 Tester needs no knowledge of implementation, including specific programming
languages
 Tester and programmer are independent of each other
 Tests are done from a user's point of view.
 will help to expose any ambiguities or inconsistencies in the specifications
White box testing: - We use this type of testing technique by observing the internal structures of
our program.
The team will use this testing technique for the following reasons:
 It is easy to find out which type of input/data can help in testing the application
effectively.
 To optimize the code
 It helps in removing the extra lines of code, which can bring in hidden defects.
 Early detection of errors during software development.
Integration Testing: - After we test each unit of the proposed system we will perform an
integration test to check whether the system meets all the functional requirements. When a
number of components are complete; it will test to ensure that they integrate well with each
other, the operating system, and other components.
Quality Assurance (system) testing:-After all of the above testing are checked we will test our
system by other peoples and we will conduct some comments how they get our system.

1.9.6 Implementation
To implement our system we will use different tools such as hypertext markup language
(HTML) for client side scripting, Java Script for validation, MySQL for database server, Apache
for web server, hypertext pre-processor (PHP) for server side scripting, and Macromedia Dream
weaver, PHP Designer, and Notepad++ for writing source codes.
1.9.7 Limitation of the Project

To keep track of the bogus profile entry, will be difficult as in the available matrimonial sites
and also system does not support the blind peoples.
1.9.8 Risk, Assumption and Constraint

 Unexpected man power failure: If we mitigated this problem, planning to cover the tasks
of the victim with the remaining team members.
 Virus attack on computer: By using the backup server; duplicate files more than on two
computers; backup files on Internet mail boxes, external devices etc... We can resist the
problem.
 Failure of electric power: to mitigate this problem we used personal resources like laptop.
 Time management problem: We tried to solve this problem using proper schedule for
each phase of the project until this phase and cooperative work among the team, but it
was difficult to manage it completely.

Chapter Two: Introduction of Existing System
Existing system covers the description of the existing system, problem of the existing system and
what issues the proposed system going to improve and details about functional and non-function
requirements of proposed system.
2.1 Introduction of Existing System

Currently existing system in our country related to marriage are individual negotiation, helps of
broker (agent) between bride and groom, by expressing feeling through media (FM radio) and
some sites which cannot enough to success their interest of two people because of its stands for
only see image and send some text. Like lovehabib.com…
Some defects in existing system are:
 Individual searches groom or bride based on limited area means from related
environments only.
 Agent may depend on his/her business rather than groom’s and bride’s interest.
 Some media also expresses simply peoples feeling and cannot attend or follow to
accomplish their interest.
2.2Players in the Existing System

Existing systems encompasses different players (actors) to carry out the job. Among those
different actors (players), the following are some:-
Groom and Bride: two people who are interested for marriage.
Agent: broker or third person between those two peoples, sometimes we can mention as
elders in tradition culture special in our country.
Media: we can also take media as one player, because it uses to communicate between bride
and groom.

2.3 Major functions/activities in the existing system like inputs, processes & outputs
Input:
Major activities in existing system can be taken as inputs the following components to provides
match for person interested in marriage :-
 More personal details of individuals

 Physical attributes
 Education and occupation
 Habits
Processes:
Agents or media players perform the following process depending on above process:-
 Search bride or groom based on their inputs. May found or not.

 After joins bride or groom according to ones inputs, try to communicate and then express
feeling from one side. This task may be performed by agents or other players.
 Then inform result for interested groom or bride
 Finally, the players may communicate or join those two peoples to finalize the issues of
marriage.
Output:
After taking the above inputs and processing them, the agents or media provides the following
results or outputs.
 The two parties interested for marriage will join each other and can arrange or set
wedding dates
 When both families agreed for the wedding, where many guests are invited, there can
have different ceremonies including Dances and Music.
 Finally, Bride and Groom becomes one family in order to success their dreams.
2.4Business rules
As mentioned above, the existing system follow to provide a match through Agents, Media and
other traditional methods, the major business rules in the existing system are the following:-
 Both bride and grooms have to more than 18 years.
 The bride or grooms have to inform necessary information according to their interest for
agents or media.
 The bride or grooms have to promise with agent some money or other.
 Agent has to find match according to the two people’s interest.
 After, the bride or grooms inform all necessary information for the media with an
agreement that, the media have to broadcast those information for the society.
2.5Report generated in the existing system

In the existing system there are different kinds of reports which are generated for match
purposes. Those reports include report from agent and report from media.
Report from agent:-the agents provide some forms for bride or grooms by considering their
information. In addition of that, when this two people are getting ready for marriage, the agents
follows until the marriage is over by arranging the whole wedding ceremony.
Report from media:-the media can provide the reports for both society and bride or grooms in
the form of publicity. When we say this, the media generate report for bride or grooms
depending on their required information for finding match and compare the result with interested
persons. And also media can be provide report for society depends on the result from previous
match to motivate the society and increase the interest of society find match for marriage
through media.

2.6Forms and other documents of the existing systems[ CITATION Sos04 \l
1033 ]
Figure 1 form of existing system
2.7Bottlenecks of the existing system
2.7.1 Performance
Obviously, as long as the existing system is manual and needs agents or media between two
persons, response time is very slow and inefficient.
2.7.2 Input and Output
The existing system mainly involves through agents or media to describe detail information
about groom and bride as Input and processed it to give better match for two people. However,
that result is not comfortable for the people, in case of agent’s interest is more on benefit rather
than the interest of groom and bride. Getting a better match through media is also happening
rarely.

2.7.3 Security and Controls
In the existing system, there is no specific security for activities through agents and media.
Redundancy and missing information of groom and bride in the present system is common. It’s
not secured as enough.
2.7.4 Efficiency
Existing system has issues on its efficiency as well. The bride and groom have to depend up on a
third party to find their perfect match. Since they use agents or media, it may consume lots of
money and time. Hence, the existing manual system is not as efficient as enough.
2.8Practices to be preserved
Here most of the main activities that are performed in the current system will be preserved by
manual replication of activities. That is each activity that is applicable to the system are designed
and automated to achieve the best functionality. The team is going to develop a new system that
might overcome those problems under the existing system. These new system will be a web
based one that will change the way the current system operates, and services given to its users.
2.9Proposed solution for the problems of the existing system

Even though the existing system provides different functions that are stated above, it is not to
mean that those functions are satisfactory. This is because all the processes (actions) performed
are not effective and efficient. To overcome or improve these operations, the team comes up with
a new proposed system Ethio-Matrimony. This new system is a Web based application that
enables the users to access many services given by the system through the Internet. The new
system is targeted to address the problems of the current system and to support additional
functionalities. Based on the user inspection, the proposed system can hold a user friendly
environment, which also incorporates some local language interface.
Some of the new systems that solve the existing system are:-
 Easy way to join bride and groom based on their interest.

 Storing and maintaining data in database.
 Give fast service to the bride and groom.
 Easy to exchange information through online effectively without necessity of third
body.

 Not need more human power and money.
 Security of data
 Perfect match making
 Effective and interactive chatting
 Notification service
 User friendliness and interactive
2.10 Requirements of the Proposed System
2.10.1 Functional requirements

Functional requirements describe the interactions between the system and its environment,
independent of its implementation. The environment includes the user and any other external
system with which the system interacts. These are statements of services the system should
provide, how the system should react to particular inputs, and how the system should behave in
particular situations. It specifies the software functionality that the developers must build into
the product to enable users to accomplish their tasks. The main purpose of functional
requirements within the requirement specification document is to define all the activities or
operations that take place in the system.
Process requirements: -The proposed system shall have the ability to processes the following
functionalities:
 The system shall enable the administrator to access and manage the database
information.
 The system shall enable to advertise some information for user on its home page with
related image.
 The system shall enable to register bride and groom with their detailed information.
 The system shall enable confirmation code to verify bride and groom during
registration.
 User enters the Username and password to log in into the system.
 User can view profile, upload photos, can see match and update profile if it’s necessary.
 User can find match, send message and even can chat.

 User can search for a match by using education level, age, religion, geographical
environments…etc.
 Users have to pay some money to become a paid user.
 Administrator can generate reports and can also identify member type.
 Administrator shall have ability to delete or disable some user profile under certain
cases.
Input Related Requirements

Proposed system will accept personal details, physical attributes, educational qualification and
occupation, habits, and other necessary information as inputs during registration. User name and
password should be supplied during login. Uploading personal photos required after registration
as another input.
Output Related Requirements: -The proposed system shall have the ability to output the
following functionalities:
 System shall display successful message or error message during some operations.
 System shall display when a new user (bride and groom) is registered in the system for
the other registered members as notification.
 System shall display messages sent by another user when a particular user is logged in.
 System shall display detailed profile of other users while one registered user search for
a match.
 System shall display the dates left for user to expire his paid registration.
 System shall display some general comments.
Storage Related Requirements

The proposed system will have the ability to store all the detailed information of the groom and
bride. System also stores administrator details, user names and password required for both admin
and user.

2.10.2 Nonfunctional requirements
The team identified the following non – functional requirements for the proposed system.
And the system is expected to have the following properties.
 Efficiency - The system must process the information fastly.
 Reliability - The system should be able to perform a required function with free of
errors.
 Security -The system should be secured in that, it prevents unauthorized access into the
system. Only the administrator can be able to modify, delete, the data. All other users
have the rights only to retrieve the information from the database.
 Maintainability - The system can be restored to a specified condition within a specified
period of time.
 Reusability - the system is developed in such a way that further features can be amended
and be re-used after modification
Security and Access permissions

The system shall be secured with different secure mechanisms. In another way authentication is
provided to all the users, only authenticated users can use. It means if the user is an administrator
then he/she can be able to manage the data. All other non-registered users have the rights to see
only some information on home page and retrieve limited data from the system. In other way this
system has payment issues in order to protect system from bogus or fake users. To increase
security of users complete payment option through bank, the system can be generate secret
number that cannot be simple guess by other unauthorized users and verification will be
available when user pays for a system. .
Backup and Recovery: The proposed system has little problem to reload, backup or recover
files. Backups or recovery can be done regularly.

Chapter Three: System Analysis
3.1 Introduction
System Analysis covers the functional aspect of the whole analysis, which is Functional
modeling. We have used an object oriented methodology to analyze the requirements that are
needed to model the functionality of the proposed system. We have used different types of UML
diagrams which include use case diagram, sequence diagram, activity diagram, user interface
prototyping and analysis level class diagram to model the proposed system. Each and every
diagram has documentation to show their functionality and how they are operated.
3.2 System Requirement Specifications (SRS)

The System Requirements Specification (SRS) document describes all data, functional and
behavioral requirements of the software under production or development.
The following lists of objects are System Requirement Specifications (SRS) for Ethio-
Matrimony application.
 Use Case diagram list and their details description
 Actors list
 Sequence diagram
 Activity diagram
 Analysis level class diagram
 User Interface prototyping diagram

3.2.1 Use case Diagram
Ethio-Matrimony Use case Diagram
Login
Regisration Generate
report
Manage user
See matches and system
User
See contact
Searching
profile Administ
rator
Send/Reciev
Edit profile
e message
Payment
option Send Notification
warning
<<Extend>>
Figure 2 Use case Diagram.

3.2.2 Use case documentation (for each use case identified)
Use case documentation for Login
Use Case ID UC_01

Use Case Name Log in
Actor Administrator and Users
Description The existing users are giving his/her username& password to access their
accounts. If they are successfully login then they can edit or update their
accounts.
Pre Condition The Administrator and Users who know the password should login and
use the Ethio-Matrimony system.
Normal Action Actor’s Action System Response
Step 1: The Administrator& Step 2: The system displays the login
Users initiate to login. page.
Step 3: Administrator or Users Step 4: System checks the authentication
enter a valid user name & of username and password.
password. Step 5: System displays their
corresponding individual account.
Step 6:Usecase ends
Post condition The Administrator or Users can use different activities while first
authorized in login page.
Alternative Action Step 4: If the username and password is not validated and verified, system
displays error message and go to step 2.
Table 3 Description of Login Use case
Use case documentation for Registration
Use Case ID UC_02

Use Case Name Registration
Actor Users
Description Before using this system the user must have to register in the system. She/he has

to fill up the form and enter his/her profile in the database.
Pre Condition The Users Have registered to a system by filling necessary information
before login to Ethio-Matrimony system.
Step 1: The User wants to Step 2: The system Displays users
register in to the system. Registration page at homepage
Step 3: The users enters the Step 4: The system validates whether the
necessary information in the
information submitted is correct or not.
Users registration page.
Step 5: The system displays

Confirmation page and save the
information in the database.
Step 6:Usecase ends

Post condition Users enters all information required corresponding its validation.
Alternative Action Step 4: If the entered data is not validated and verified, system displays
error message and go to step 3 in Normal action.
Table 4 Description of Registration Use case
Use case documentation for See Matches.
Use Case ID UC_03

Use Case Name See matches
Actor Users
Description The Users registered into system see his/her matches corresponding to his/her
entered data when login to system at first time.
Pre Condition The Users Have to login to system to see matches.

Step 1: The User wants to see Step 2:The system Displays users
matches. Account page.
Step 3: The users see the

matches related to his/her Step 5:The system notices the request
entered data on its own page.
sent from user for receiver.
Step 4:The users send request
and interest for his/her
matches.
Step 6:Usecase ends
Post condition Users see all matches related to his/her interest.
Alternative Action Step 4: If there is no matches related to user entered data, system displays
no matches and go to step 2 in Normal action.
Table 5 Description of see matches Use case
Use case documentation for See Member/contact profiles.
Use Case ID UC_04

Use Case Name See Contact profile
Actor Users
Description The Administrator and Users can see member/contact profile in order to
manage user join system and to find matches respectively.
Pre Condition The Administrator and user have to login to system first.
Step 1: The User wants to see Step 2: The system Displays users
contact profile. Account page.

Step 3: The users can search
contact by using name, phone Step 4: The system display contact
number, occupation and other.
profile according to input from users.
Step 5: The users can send
request and interest after seen
Step 6: The system notices the request
individual profile.
sent from user for receiver.
Step 7: Use case ends

Post condition Users can be search to see contact profiles in order to find match.
Alternative Action Step 4: If there is no matches related to user entered data, system displays
no matches and go to step 2 in Normal action.
Table 6 Description of see contact profile Use case
Use case documentation for Edit profiles.
Use Case ID UC_05

Use Case Name Edit profile
Actor Users
Description The user can also edit his/her personal profile in the system but first he/she have
to login in the system.
Pre Condition The Users have to login into system first.
Step 1: The User wants to Step 2:The system Displays users
edit its profile. Account page.
Step 3: The users click on edit

profile button on user account Step 4:The system display detail profile
page.
of user.

Step 5:The users update all
necessary information need to
Step 6:The system store updated
update.
information in database.
Step 7:Usecase ends

Post condition Users can be update what want to update from own profile.
Alternative Action Step 4: If there is some problem when user edit own profile, system
displays error message and go to step 4 in Normal action.
Table 7 Description of Edit profile Use case
Use case documentation for payment option.
Use Case ID UC_06

Use Case Name Payment option
Actor Users
Description The most of user have to pay for system before use it in order to make our
system more secure and valuable Owner of system.
Pre Condition The Users have to Create bank account and deposit some money
Step 1: The User wants to Step 2:The system Displays Payment
option on Homepage for user.
complete payment option to
use system.
Step 4:The system send notices for
administrator page.
Step3: The Users complete
payment through bank by
transferring money for its
Step 5:Usecase ends

account to user account.
Post condition Users bank account have to balance with some money which is greater
balance transfer.
Alternative Action Step 4: If Users balance is empty or low in account, system displays error
message and go to step 2 in Normal action.
Table 8 Description of Payment option Use case
Use case documentation for Generate report.
Use Case ID UC_07

Use Case Name Generate report.
Actor Administrator
Description The Administrator generates report daily, weekly and monthly in order to specify
paid member and to know full statistics of system.
Pre Condition The Administrators hhave to login to system first.
Step 1: The Admin wants to Step 2:The system Displays Admin page
generate report for different
activity in system. Step 4:The system display generates
report option: daily, weekly and monthly.
Step3: The Admin click on
generate report option on its Step6: System display report generate by
page. Admin on Admin page.
Step5: The Admin generate Step 7:Usecase ends

depend on generate report

option in Step 4.
Post condition Admin have permission to generate report for any activity in system.
Alternative Action Step 4: If some problem exist during admin generate report, system
Table 9 Description of Generate report Use case
Use case documentation for Manage user and system.
Use Case ID UC_08

Use Case Name Manage user and system
Actor Administrator
Description The admin can add, update or delete the records in the database.
Pre Condition The Admin have to login to system first.
Step 1: The Administrator Step 2:The system Displays Admin page.
wants to Add/Modify/Delete
information on system and Step 4:The system store all update
user account. information and display.
Step3: The Administrator
Add/Modify/Delete necessary
information on system. Step 5:Usecase ends
Post condition Administrator has full permission to manage system effectively.
Alternative Action Step 4: If some problem when Administrator update system, system

Table 10 Description of Manage user and system Use case
Use case documentation for Searching
Use Case ID UC_09

Use Case Name Searching
Actor Administrator & Users.
Description The systems have different search option on homepage and Admin/Users page
like quick search, advanced search and contact search.
Pre Condition The Administrator and Users have to enter some data on search box.
Step 1: The Admin and users Step 2:The system Displays Search form
on Homepage and Admin/User page.
want to search some value.
Step 4:The system display result depend

Step3: The Administrator and
on enter data
Users enter valid data in
search box to get result.
Step 5:Usecase ends

Post condition System display result exists in database.
Alternative Action Step 4: If Admin/Users enter invalid data, system displays error message
and go to step 2 in Normal action.
Table 11 Description of Searching Use case

Use case documentation for Send/Receive message.
Use Case ID UC_10

Use Case Name Send/Receive message
Actor Administrator and Users
Description The users can send/receive necessary information each other in order to
find match depend on its interest and also chat each other.
Pre Condition The Users have to login to system first.
Step 1: The User wants to Step 2:The system Displays users
send message or interest to Account page.
other users
Step 3: The users click on Step 4:The system display send message
send message button on user
form for user.
account page.
Step 5:The user writes own

Step 6:The system notice message from
interest/message on prepare
area and send for receiver by sender to receiver.
selecting user from list of
contact.
Step 7:Usecase ends
Post condition Users can be send/receive interest through system.
Alternative Action Step 4: If Users try to send message without any text, system displays
error message and go to step 4 in Normal action.
Table 12 Description of Send/Receive Use case

Use case documentation for Notification
Use Case ID UC_11

Use Case Name Notification.
Actor Administrator
Description The system display notification when new user complete payment and register to
system for Admin and also notices for user when new users join system.
Pre Condition The Administrator and Users have to login to system first.
Step 1: The Admin and users Step 2:The system Displays Admin page
and user account page for Admin and
want to see notification from
Users respectively.
system.
Step3: The Administrator and Step 4:Usecase ends

Users see notification on its
page.
Post condition System automatically displays notification on the Admin page and User
page.
Alternative Action Step 4: If there is no new notification, system displays previous
notification and go to step 2 in Normal action.
Table 13 Description of Notification Use case

Use case documentation for Send warning
Use Case ID UC_12

Use Case Name Send warning
Actor Administrator.
Description The Administrator send warning for users when a user try deal some problem on
system and to notify remain day of payment for users .
Pre Condition The Administrator have to login first.
Step 1: The Admin want to Step 2:The system Administrator page.
send warning.
Step 5: The system display warning sent
from admin for users on user account.
Step3: The Admin click on
send warning.
Step 6:Usecase ends

Step4: The Admin search
users from contact by using id
and send.
Post condition Users see what any information sent from Administrator.
Alternative Action Step 4: If Admin/Users enter invalid data, system displays error message
and go to step 2 in Normal action.
Table 14 Description of Send warning Use case

3.2.3 Sequence diagram
Sequence diagram shows interaction between objects over a specific time.
Sequence diagram for Login
login to ethio- user login login System User Profile

matrimony <<actor>> <<ui>> <<controller>> <<database server>> <<ui>>
1: wants to login
login page in
use
user name and

Enter user name password
and password
request for
validation authenticate
request for
validation
correct
validating
access user
profile
User Admin
page Dispalyed display user
profile
object deletion
Figure 3 Description of Login Sequence Diagram

Sequence diagram for Registration
:Registration :Registration
:Registration
:Home personal socio- :Profile :Database
Registration physical
detail occupation
User
click on fill-up store to

register physical data database
login page Profile is created now user can login by

user id
login using
user name and
check user name and password
id
user name and password is valid or not valid
not valid
valid user name and password
welcome user now you can edit/ update profile
Figure 4 Description of Registration Sequence Diagram
Sequence diagram for See matches

See matches notification :Database
user
user click on notification
user see matches if exists
click on match profile
see matcher profile,send

message, add as friend... update information
Object deletion
Figure 5 Description of See matches Sequence Diagram
Sequence diagram for See contact profile.

See contact :Home :Database
profile
User
Enter information of contact in search area
Search according to
Click enter key or search button
given information
Display user
search result
Give information
Object
deletion
Figure 6 Description of See contact profiles Sequence Diagram
Sequence diagram for Edit profile.

profile :upload image :Database
Edit profile
user
update information
give remaining edit profile
store database
fillup form and click on update
click on upload image
browse image
click on upload photo

photo uploaded
Figure 7 Description of Edit profile Sequence Diagram
Sequence diagram for Payment option.

:Home page :Network to bank :Database
Payment option
user
select payment option

verify user account
1, user enter correct account
number return status store record
return status
error message
2, user enter wrong account
number
error message
Object deletion
Figure 8 Description of Payment option Sequence Diagram
Sequence diagram for Generate report.

Admin home
Database
page
Generate report Admini
strator
click on gnerate report
select report generate option, mon,weekly

generate report according to
given information
click on generate report button
Display
generated report
display generated report
object deletion
Figure 9 Description of Generate report Sequence Diagram
Sequence diagram for manage user and system.

Admin home
Database
Manage user page
and system Admini
strator
click on administrator page

Display admin
page
display administrator page
add, delete, modify necessary information
activate,deactivate user account

store update
Display success
message display updated/managed sucessfully
object deletion
Figure 10 Description of Manage user and system Sequence Diagram
Sequence diagram for Searching

:Searching :Database
Searching Both
actor
click on search
search option
Display search
option
select option
give form according search selection
fillup information required in given

form
search according given information
Display result given result
Object relation
Figure 11 Description of Searching Sequence Diagram
Sequence diagram for Send/Receive message

:Home page :Profile :Message :Database
Send/Receive
message
user
click on login
Displayed login
page Login page
Enter username and

password check username and password valid
username and password is valid or invalid
not valid
username and password valid Identify receiver
click on message
Display User account
Displayed User write message
account click on send button store sent message
display sent message for receiver
object deletion
Figure 12 Description of Send/Receive message Sequence Diagram
Sequence diagram for Notification

Notification :Home page :Profile :Database
Administ
rator
click on login
Display login
page
login page
enter password and user check password and user name

1.Enter wrong user name
name and password
user name and password valid or invalid
not valid
2.Enter valid user
name password
valid user name and password
Display user display user account

account user click on notification
See notification
Object deletion
Figure 13 Description of Notification Sequence Diagram
3.2.4 Activity Diagram

Activity diagram is basically a flow chart to represent the flow form one activity to another
activity. The activity can be described as an operation of the system.
Activity Diagram for Login

Login
Enter use r name and

passw ord
Incorrect
Validate
Correct
Displa y Account
profile
Logout
Figure 14 Description of Login Activity Diagram
Activity Diagram for Registration

Register
Enter full required

information
NO
Vaildate
Registered
Login
Enter user name

and password
Validate NO
YES
Display account
profile
Logout
Figure 15 Description of Registration Activity Diagram

Activity Diagram for See matches
Assume User already Login
See Matches
Notification
NO YES
If matches exist
See matches
Send interest
Logout
Figure 16 Description of See matches Activity Diagram

Activity Diagram for See contact profile
See contact profile
Search by using id/name and

other
YES
NO
Is result found
See profile
Send interest if possible
Logout
Figure 17 Description of See contact profile Activity Diagram

Activity Diagram for Edit profile
Edit profile
Update necessary
information
NO
Validate
YES
Update profile
Upload photo
Logout
Figure 18 Description of Edit profile Activity Diagram

Activity Diagram for Payment option
Payment option
Enter account number
Incorrect
Verify account
number
Transfer money
Correct
Store in database
Figure 19 Description of Payment option Activity Diagram

Activity Diagram for Generate report
Assume Administrator already Login
Generate report
Select report option
Incorrect Is correctly
Generated
Correct
Display report
Logout
Figure 20 Description of Generate report Activity Diagram

Activity Diagram for Manage user and system
Manage user and system
Add/ Delete/ Modifynecessary

information
Store change in database
Display change
Logout
Figure 21 Description of Manage user and system Activity Diagram

Activity Diagram for Searching
Assume both actor already Login
Searching
Select search option
Enter what we want to

search
No
Is result found
Yes
no result
found
Display result
Figure 22 Description of Searching Activity Diagram

Activity Diagram for Notification
Notification
NO Is there new
notification
YES
See old one
see new one
Logout
Figure 23 Description of Notification Activity Diagram
Type equation here .

3.2.5 Analysis level class diagram (conceptual modeling)
The class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The class diagrams are widely used in the modeling of object oriented
systems because they are the only UML diagrams which can be mapped directly with object
oriented languages.
User register() Registration

-full name
-Age Administrator
-Sex 1..*
+Register()
-Marital -Full name 1
status -mail id
-Active session Notification 1..*
-Height
-Weight +Manage_user()
Report generate
-Education +Notify()
-Occupation +Report_generate()
-Religion +Mail() +All member()
1..* 1
-Country +Modify() +Paid member()
-City +Delete() +Free member()
+Logout
1 Notification
+Register()
message
+Modify 1
1..* 1 +Notify()
+Drop()
1 Login
-User name Message

-Password
-from
search
+Login() -to
-body
1..*
+Send()
+Receive() 1..*
+time()
Bank
1 1
-Full name
-Account NO Searching
+Create()
+Deposit() +Search()
+Withdraw
+Check
Figure 24 Description of Class Diagram

3.2.6 User Interface Prototyping
Ethio-Matrimony
Home page
Advanced Member Payment

Home About Us Login Register
search profile option
User Admin
Enter
personal
detail
Home My profile Message Notification Search Report Fill physical

Home Notification Mail
generate detail
Edit profile See new

notify Fill socio-
Logout occupation
See matches
Send/Receiv
e message Logout
Update All member
information Manage user
See new and system
Chat feedback
Free Send/Read
Update photo member mail
Delete profile
Paid
member
Create album
Add/Modify/dele Send warning
Search by Search by Search by te content of
name professional location system
Hide profile
Delete mail
Figure 25 Description of Prototype Diagram

3.2.7 Supplementary specifications
The Supplementary Specifications capture the system requirements that are not readily captured
in the use cases of the use-case model. Such requirements include:-
 Legal and regulatory requirements and application standards.

 Quality attributes of the system to be built, including usability, reliability, performance,
and supportability requirements.
 Other requirements such as operating systems and environments, compatibility
requirements, and design constraints.
The other Supplementary specifications are the business rules .The business rules is a principle
or a policy in which the proposed system operates accordingly. It deals with access control issue.
Some of the business rules that we have included in this project are the following:
 Unregistered person have no permission to get more information of the system.

 Users can verify during registration.
 Users complete payment option to get full access of system.

Chapter Four: System Design
4.1 Introduction
This chapter contains the designing and architectural parts of Ethio-matrimony website. In this
project we use object oriented system development methodology. The objectives of design are to
model the system with high quality. To have high quality of system that depends on the nature of
design created by the designer. If the system needs to repair, the whole process will be dependent
on system design, so if the whole system is designed effectively and precisely then it is easy to
make changes in the system.
4.2 Class Type Architecture

The class type architecture of this project has the following layers:- Interface layer, control
layer/process layer, business/domain layer, Persistent layer and data source layer. This
architecture describes how the system works and interacts with the user by dividing work into
different layers.
User interface layer
Control/Process layer
Business/domain layer
system layer
persistence layer
Data source
Figure 26 Class Type architecture

Layers Descriptions

Interface layer This layer is a layer that the user interacts with Ethio-
matrimony website, which means it provides the user access to
the system
Process/application layer This layer is a layer of different process or applications of the

system like registration , see matches ,language options ,
chatting and so
Business/domain layer This layer checks whether the user pay his monthly or annual
payment to use the system.
Persistent layer This layer encapsulates the capability to store, retrieve and
delete objects or data.
System layer This layer provides operating system specific functionality for
the system. System layer also communicate all of the
remaining four layers
Table 15 class type modeling
4.3 class modeling

-full name:varchar()
-Age:int() Administrator
-Sex:varchar() 1..* +Register()
-Full
-Marital status:varchar() name:varchar()
-Height:varchar() -mail id:int Notification 1..*
-Weight:varchar() -Active session
-Education:varchar() Report generate
+Manage_user()
-Occupation:varchar() +Notify() user_id:int
-Religion:varchar() +Report_generate() username:varchar()
-Country:varchar() 1..* 1 +Mail() +All member()
1 -City:varchar() +Modify() +Paid member()
+Delete() +Free member()
+Logout
Notification
1
+Register()
message
notification_id:int
+Modify 1..*
1 user_id:int
1 datetime:varchar()
+Drop()
1 Login status:varchar()
1 1
-User name:varchar() +Notify()
-Password:varchar()
1
1 +Login() Message
Friend chat -from:varchar()
1..*
friend_id:int chat_id:int -to:varchar()
user_id1:int sender:varchar() 1..* -body:text
user_id2:int reciever:varchar()
Bank +Send()
status:varchar() datetime:varchar() post
datetime:varchar() 1 +Receive()
send() -Full name 1
post_id:int +time()
receive() -Account NO
addfriend() user_id:int
confirm() 1 post_txt:varchar()
reject() +Create() post_picture:varchar()
comment +Deposit()
+post()
+Withdraw
comment_id:varchar() +Check
post_id:int
user_id:int
comment_txt:varchar()
comment()
Figure 27 Class Modeling

4.4 State chart modeling
State chart for

login
Enter Enter user name Valid

Login Display the page
and password
Invalid
Close
Figure 28 State chart diagram for login
State chart for

Register
successful
Enter required Registered
Register
information message
Not successful
End Display account

Close
profile
Figure 29 State chart diagram for register

state chart diagram
for see matches
If matches Send
See matches Read notification
interest/Request
No matches
End
Close
Figure 30 State chart diagram for see matches
State chart diagram

for Payment option
Enter account valid account number

payment option Transfer money
number
Invalid account number
Store in database
End process
Close
Figure 31 State chart diagram for payment option

Manage user and
system
Manage user Add/Delete/Modify Store changes in

and system necessary information Database
End Display change

close
in database
Figure 32 State chart diagram for manage user and system
Update profile
Update necessary valid information

Edit profile Update profile
information
Not valid
information Upload photo
End
close
Figure 33 State chart diagram for update profile
4.5 Collaboration modeling

Figure 34 Collaboration diagram for login
create 1. register user

Registration
2.validate system controller
<<UI>>
user 2.1 error message
2.2 send information

3. view information()
Registration
View controller <<database>>
Figure 35 collaboration diagram for registration

create 1.check
search
system
<<UI>>
controller
user
1.1 search
phone
name email
number
system
<<database>>
Figure 36 Collaboration diagram for search user

4.6 Component Modeling
notification
see matches
see contact
profiles
edit profile
generate
report
user administrator
register
send and
receive
message
send
warninig
chat
send and
accept
request
post
Figure 37 Component diagram
4.7 Deployment modeling

Clint server Application server Database server
Login
User
Security
See
matches
Generate
report
Edit profile
Searching
Administrator
Registration
Payment
option
See Database
contact
Send/reciv
e message
Manage user
and system
Figure 38 Deployment diagram
4.8 Persistence modeling

-full name
-Age Administrator
-Sex 1..* +Register()
-Full name 1
-Marital status -mail id
-Height -Active session Notification 1..*
-Weight +Manage_user()
-Education Report generate
+Notify()
-Occupation +Report_generate() user_id
-Religion +Mail() username
-Country 1..* 1 +Modify() +All member()
1 -City +Delete() +Paid member()
+Logout +Free member()
1
+Register() 1
message
Notification
+Modify 1..* 1
+Drop() notification_id
1 Login user_id:
1 1 datetime
-User name status
-Password
1 +Notify()
1 +Login() Message
Friend chat -from
1..*
friend_id chat_id -to
user_id1 sender 1..* -body
user_id2 reciever
Bank +Send()
status datetime post
datetime 1 +Receive()
send() -Full name 1
post_id +time()
receive() -Account NO
addfriend() user_id
confirm() 1 post_txt
reject() +Create() post_picture
comment +Deposit()
+post()
+Withdraw
comment_id +Check
post_id
user_id
comment_txt
comment()
Figure 39 persistent diagram
4.9 User Interface design

Figure 40 Home page by English
Figure 41 User login page

Figure 42 Admin login page
Figure 43 Amharic home page

Chapter Five: Implementation & Testing
1.1 Introduction
In this phase we have turned the physical design specification into working computer code, and
then the code is tested until most of the errors have been detected and corrected. The purpose of
this activity is to convert the final physical system specification into working model with reliable
software and hardware. So the team has worked for converting all the documents gathered and
designed into the code.
1.2 Final Testing of the system
Testing is a process to show the correctness of the program and designed to analyze the logic
used in the implementation of the System. In this system all errors in the forms, functions and
modules have been tested. To test the whole system the team follows the following procedures.
1.2.1 Unit testing:

Every module of the System is separately tested. (i.e. the team tests every module by applying
some selection mechanism). Through this mechanism every modules gets tested. If an error
occurs correction will be taken without affecting another module.
1.2.2 Integrated tasting

All the modules will be combined together and tested for whether it fits with each other and with
the systems functionality. If error occurs in combining them, the module with problem will be
identified and recombined.
1.2.3 Black box testing

Black Box Testing attempts to find errors in following areas or categories, incorrect or missing
functions, interface error, errors in data structures, performance error and initialization and
termination error. The team has conducted this testing procedure to evaluate only the outputs
generated in response to selected inputs and execution conditions
1.2.4 White box testing

White-box testing tests internal structures or workings of a program, as opposed to the
functionality exposed to the end-user. The team has conducted this testing procedure during writing

the code for each desired components of the system to check if the written code is working properly or
not.
1.2.5 Functional (black box testing) and system testing

In this testing mechanism, the team performs over all functional testing by checking whether it
meets or not meets the required target.
Compatibility tasting
 Hardware Compatibility test- the system is compatible with all the Hardware and
Software listed under the Hardware and Software Acquisitions.
 Software compatibility test – the system is compatible with all the software listed under
the development tool.
User interface tasting
the team has conducted this testing procedure to evaluate the GUI elements like field forms drop
down box, input type length, radio button are work properly and suitable for the users. As a
result all of these components are working properly.

Test case id: ET-M -TEST CASE 01
Testing class: Black box and white box test
Testing name: unit and integration test
Unit to test: User login
Assumptions: login in to user account
Test data: User name (valid user name, invalid user name, empty user name)
Password(valid password, invalid password, empty password)
Steps to be executed Data Expected results
(description)
Enter valid user name and user name =xxx Well come ”full user name”
password =***
valid Password.
Enter valid username and user name =xxx “wrong password please
invalid password. password =***
reenter the correct password’
Enter invalid user name and user name =xxx “wrong user name please
password =***
valid password. reenter the correct user name”
Enter invalid user name and user name =xxx “wrong user name and
password =***
invalid password. password please reenter”
Enter empty username and valid user name = _ _ _ “user name cannot be empty”
password =***
password.
Enter valid username and empty user name = xxx “please enter password”
password =_ _ _
password.
Enter all fields empty user name = _ _ _ User name and password
password =_ _ _
cannot be empty
Table 16 Test case – 01
Sample code
///login.php
<head>

<script type='text/javascript'>
functionuser_formValidation(){ //assign the fields
varuname = document.getElementById('inputEmail');
var password = document.getElementById('inputPassword'); // Check your input in the order that

it appears in the form!
if(notEmpty(uname,"Enter UserName!")){
if(notEmpty(password,"Enter Password")){
return true; }}
return false; }
functionnotEmpty(elem, helperMsg){
if(elem.value.length ==0){
alert(helperMsg);
elem.focus();
return false;
return true; }
</script>
</head>

<div id="user" class="modal hide fade" tabindex="-1" role="dialog" aria-

labelledby="myModalLabel" aria-hidden="true">
<div class="modal-header">
</div>
<div class="modal-body">
<div class="alert alert-info">
<button type="button" class="close" data-dismiss="alert">×</button>

<strong>Login User!</strong> Please Enter the Details Below.
</div>
<form class="form-horizontal" method="post" onsubmit='return user_formValidation()'

enctype="multipart/form-data">
<div class="control-group">
<label class="control-label" for="inputEmail23">Username</label>
<div class="controls">
<span class="input-group-addon"><i class="icon-user icon-large"></i></span>
<input type="text" name="username" id="inputEmail" placeholder="Username">
</div>
</div>
<div class="control-group">
<label class="control-label" for="inputPassword12">Password</label>
<div class="controls">
<span class="input-group-addon"><i class="icon-lock icon-large"></i></span>
<input type="password" name="password" id="inputPassword" placeholder="Password">
</div></div>
<div class="control-group"><div class="controls">
<button type="submit" name="login" class="btnbtn-info"><i class="icon-signin icon-

large"></i> Sign in</button>
</div>
</div></form>
<?php
if (isset($_POST['login'])) {
function clean($str) {
$str = @trim($str);

if (get_magic_quotes_gpc()) {
$str = stripslashes($str); }
return mysql_real_escape_string($str); }
$UserName=clean($_POST['username']);
$Password=clean($_POST['password']);
$query="SELECT * from user WHERE UserName='$UserName' AND

Password='$Password'";
$run=mysql_query($query);
if(mysql_num_rows($run)==1){
//if($run!=0){
while($row=mysql_fetch_array($run)){
$dbuser=$row['UserName'];
$dbpasw=$row['Password'];
$dbsex=$row['sex'];
$dbid=$row['user_id'];
$dbemail=$row['email'];
if($UserName==$dbuser&& $Password==$dbpasw){
session_start();
session_regenerate_id();
$_SESSION['se_user']=$UserName;
echo "<script>window.location='Home1.php'</script>";}}

Unit to test: User register
Assumptions: user register successfully

Test data: full name:(valid name, invalid name, empty name )
Sex(valid sex, empty sex)
Age(valid age, empty age)
Country(valid country, empty country)
city(valid city, empty city)
Marital status(valid marital status, empty marital status)
Height(valid height, empty height)
Weight(empty weight)
Occupation(empty occupation)
Religion(empty religion)
Steps to be executed (description) Data Expected results
Enter valid full name, sex, age, country, full name: xxx “registered success fully”
city, marital status, height, weight, sex: x
occupation, religion. age: xx

country: xxx
city: xxx
marital status: xxx
height: xxx
weight: xx occupation:
xxx
religion: xxx
Enter empty full name, sex, age, country, full name: _ _ _ “please fill all required
city, marital status, height, weight, sex: _ information”
age: _ _
occupation, religion.
country: _ _ _
city: _ _ _
marital status: _ _
height: _ _ _
weight: _ _
occupation: _ _ _
religion: _ _ _
Table 17 Test for registration
Sample code
/////registration.php
<?php include('head.php')?>
<?php //Function to sanitize values received from the form. Prevents SQL injection

$str = @trim($str);
if(get_magic_quotes_gpc()) {
$str = stripslashes($str); }
return mysql_real_escape_string($str); }
/// $vuname = ""; $vpassword=""; $vphone=""; $vemail="";
$vseek=""; $vsex="";
$a=""; $u=""; $e=""; $s=""; //
$uname = ""; $password = ""; $email=""; $phone="";
if (isset($_POST['save'])) {
//Sanitize the POST values
$image = addslashes(file_get_contents($_FILES['image']['tmp_name']));
$image_name = addslashes($_FILES['image']['name']);
$image_size = getimagesize($_FILES['image']['tmp_name']);
move_uploaded_file($_FILES["image"]["tmp_name"], "admin/photo/" . $_FILES["image"]

["name"]);
$location = "admin/photo/" . $_FILES["image"]["name"];
$uname=$_POST['username'];
$password=$_POST['password'];
$email=$_POST['email'];
$phone=$_POST['phone'];
$sex=$_POST['sex'];
$seek=$_POST['seek'];
$for1=$_POST['for_who'];

$day=$_POST['day'];
$month=$_POST['month'];
$year=$_POST['year'];
$country=$_POST['country'];
$state=$_POST['state'];
$age=2016-$year;
$pattern = "/^([a-z0-9])(([-a-z0-9._])*([a-z0-9]))*\@([a-z0-9])(([a-z0-9-])*([a-z0-9]))+(\.([a-z0-
9])([-a-z0-9_-])?([a-z0-9])+)+$/i";
//Input Validations
if (!preg_match($pattern,$email)){
$e = "Invalid Email Address"; }
if ($email=="") {
$e = ""; }
if ($uname=="") {
$vuname = "<td>userName Missing.</td>";
}else{
$vuname=""; }
if ($password=="") {
$vpassword = "<td>Field Missing.</td>"; }
else{
$vpassword=""; }
if ($email=="") {
$vemail = "<td>Field Missing.</td>";
} else{
$vemail="";}

if ($seek=="") { $vseek = "<td>Field Missing.</td>";
} else{ $vseek=""; }
if ($sex=="") {
$vsex = "<td>Field Missing.</td>";
} else{ $vsex=""; } //Check for

duplicate login ID
if($uname != '' && $email!='' && $phone!='') {
$query = "SELECT * FROM user WHERE username='$uname' or email='$email'

or phone='$phone'";
$result = mysql_query($query);
while($row=mysql_fetch_assoc($result)){
$un1=$row['username'];
$em1=$row['email'];
$ph1=$row['phone'];
if($un1==$uname){
$u='This username already exist:   <u>'.$un1;'</u>'; }
if($em1==$email){
$e='This username already exist:   <u>'.$em1;'</u>'; }
if($ph1==$phone){
$a='This phone Number already exist:   <u>'.$ph1;'</u>'; }
if($seek==$sex){
$s='Not support same sex'; }
/* if($result) {
if(mysql_num_rows($result) > 0) {
$u = 'UserName already in use'; }

@mysql_free_result($result); }
else { die("Query failed");} */ }
if($uname!= "" && $seek!= $sex && $password!= "" && $phone!="" &&preg_match($pattern,
$email) ) }

Unit to test: payment option
Assumptions: successful paid user
Test data: choose email(valid email, invalid email, empty email)
Phone number (valid phone number, invalid phone number, empty phone number )
Amount of money(valid amount, empty amount)
Valid email, phone number, amount email: xx@x.x An alert message
of money phone number: xxx “Successfully paid”
amount of money: xxx
Invalid email and phone number Email: xx@x.x An alert message” please enter
correct phone number or
Phone number: xx
email”
Valid phone number and invalid email Phone number :xx An alert message “invalid
Email: xx@x.x email format please enter
correct email”
Invalid phone number valid email Phone number: xx An alert message “invalid
Email: : xx@x.x phone number format please
enter correct phone number”
An alert message “invalid email Phone number: xx An alert message “Please fill
all the required information”
format please enter correct email” Email: : xx@x.x
Amount of money:xxx
Table 18 Taste case 03
Sample code
Payment.php
<?php include('head.php')?>
<?php
//Function to sanitize values received from the form. Prevents SQL injection

$str = @trim($str);
if(get_magic_quotes_gpc()) {
$str = stripslashes($str);}
return mysql_real_escape_string($str);}///
$vphone="";
$vemail="";
$a="";
$u="";
$e="";//
$email="";
$phone="";
if (isset($_POST['create'])) {
//Sanitize the POST values$account = '';
for ($i = 0; $i<10; $i++) {
$account .=mt_rand(0,9) }
$email=$_POST['email'];
$phone=$_POST['phone'];
$amount=$_POST['amount'];
$pattern = "/^([a-z0-9])(([-a-z0-9._])*([a-z0-9]))*\@([a-z0-9])(([a-z0-9-])*([a-z0-9]))+(\.([a-z0-
9])([-a-z0-9_-])?([a-z0-9])+)+$/i";

//Input Validations
if (!preg_match($pattern,$email)){
$e = "Invalid Email Address"; }
if ($email=="") {
$e = "";}
if ($email=="") {
$vemail = "<td>Field Missing.</td>";} else{
$vemail="";}
//Check for duplicate login ID
if($email!='' && $phone!='') {
$query = "SELECT * FROM user WHERE email='$email'";
$result = mysql_query($query);
while($row=mysql_fetch_assoc($result)){
$em1=$row['email'];}
if($em1!=$email){
$e='You have to enter email known by system :   <u>'.$email;'This email is

invalid</u>';}}
if($phone!="" &&preg_match($pattern,$email) ) {
$query = mysql_query("INSERT INTO bank(email,phone,account_number,amount)

values('$email','$phone','$account','$amount')")or die(mysql_error());
echo'<div class="alert alert-error">
<button class="close" data-dismiss="alert">×</button>
You have registered successfully !!
</div>';
echo'This is your account number:   .'.$accuont;}}
?>

<html>
<head>
<script type='text/javascript'>
functionbank_formValidation(){
//assign the fields
var amount = document.getElementById('amount1');
varPhoneNumber = document.getElementById('phone1');
// Check your input in the order that it appears in the form!
if(isNumeric(amount, "please fill your amount number only")){
if(notEmpty(amount,"amount required")){
if(notEmpty(PhoneNumber,"phone number required")){
if(phoneValidator(PhoneNumber,"please fill your valid PhoneNumber")){
return true;}}}}return false;}
functionphoneValidator(elem, helperMsg){
varphoneExp = /^\d{3}\d{3}\d{4}$/;
if(elem.value.match(phoneExp)){
return true;
}else{
alert(helperMsg);
elem.focus();
return false;
}}

functionnotEmpty(elem, helperMsg){
if(elem.value.length ==0){
alert(helperMsg);
elem.focus();
return false;}
return true;}
functionisNumeric(elem, helperMsg){
varnumericExpression = /^[0-9,-,/]+$/;
if(elem.value.match(numericExpression)){
return true;}else{
alert(helperMsg);
elem.focus();
return false;}}
</script>

Unit to test: search contact
Assumptions: display required person
Test data: name(valid user name, invalid user name, empty user name)
Email(valid email, invalid email, empty email)
Phone number(valid phone number, invalid phone number, empty phone number)

Valid user name , email, phone user name : xxx Displays the searched person
number email: xx@x.x
phone number: xxx
Valid user name empty email and user name : xxx Displays the searched person
phone number email: xx@x.x
phone number: xxx
Valid email or phone number empty user name : xxx Displays the searched person
user name email: xx@x.x
phone number: xxx
Invalid email, phone number , user user name : xxx Displays empty search box
name email: xx@x.x
phone number: xxx
Table 19 Test case 04
Sample code
Contact_search.php
<?php
session_start();
if(isset($_SESSION["se_user"])){
$session_id=$_SESSION["se_user"];
$session_sex=$_SESSION["se_sex"];
$ses_id=$_SESSION["se_id"];
?>
<?php
if(isset($_POST['name'])){
$name=trim($_POST['name']);
$query2=mysql_query("SELECT * FROM user WHERE UserName like('%$name%') OR email

LIKE '%$name%' and sex!='$session_sex' limit 0,5");
$count=mysql_num_rows($query2);
echo "<div id='search'>";

while($query3=mysql_fetch_array($query2)){
if($session_id==$name){
?>
<div id='result' style=" text-decoration:none; text-transform:capitalize; color:#3B5998;"

onclick='fill("<?php echo $query3['User']; ?>")'><a href="#"><img class="imgimg-rounded"
style="padding:5px;" src="<?php echo $query3['image']; ?>" width="70" height="70">
  <?php echo $query3['UserName']; ?>(Me)</div>
<?php }
else{
?>
<div id='result' onclick='fill("<?php echo $query3['UserName']; ?>")'><a

href="view_profile.php?id=<?php echo $query3['user_id'];?>"><img class="imgimg-rounded"
style="padding:5px;" src="<?php echo $query3['image']; ?>" width="70" height="70">
  <?php echo $query3['UserName']; ?></div>
<?php }
?>
<?php
}}
?>
1.3 Hardware software acquisitions

For the development of the system we used the following hardware and software:-
Hardware
 Printer: For printing Documentation
 Server: for connection to the client computer(to host the system)
 Computers
 Network connection materials
 CD_ROM

Software
To develop this system the following software’s are used.
 XAMPP server
 Edraw max
 Notepad++
 Mysql database server
1.4 User manual preparation
Since the system is web based, user friendly and also supports different local languages there is
no difficulties for the user to access the system. This system supports languages like Amharic
and Oromic which are spoken by majority of the population. So there is no need of preparing full
user manual. There is also some guidance messages in the home page of the system that describe
about the system.
1.5 Training
In order to provide clear information and to teach how to use this system, we will give some
awareness by using different popular social sites like facebook. There is also training by group
members for the system administrators by explaining how the system works and in what way
they can manage the system.
1.6 Installation Process

Since the project is a web based System, there is no need to install it on a particular machine
rather it will be hosted on a server.
1.7 Start-up strategy
Once the system has been published, t he user can start and access his/her authorized page by
entering the correct user name and password with proper authentication and authorization
processes but free users can access our websites without user name and password to see high
light of the website.

Chapter 6: Conclusions and Recommendations
6.1 Conclusions
Matrimonial Web Application is to provide Grooms and Brides with excellent

matchmaking experience by exploring the opportunities and resources to meet true
potential partner. Matrimonial website which will provide platform to a lot of Bride/Groom for
finding perfect match. There are different sectors like Registration, Partner Search, chatting,
editing profile, see matches, notification new user and payment option etc. So the Bride/Groom
can get their interest for find their partner. Bride/Groom can directly search Partner according to

their required criteria. This web site also supports local languages like Amharic and oromic to
help its local users to use easily by their own languages. Matrimonial web application provides
facility like quick tour. This is a module that contains the flow of the website. Here user can have
an idea how he can commit himself in the website. Matrimonial web application provides facility
to change preference about partner. This application provide facility like edit profile, update
photo and delete photo, hide profile, create album, send express interest, send personal message
and so on.
6.2 Recommandations
We strongly recommend that one who under goes through this project can succeed, if he or she
(they) pay(s) attention for expanding the system in any manner. Since the grading in not
accomplished for a full course, it can be improved. Adding audio video chatting, Taking two
person who match each other through this system up to marriage day in order to success
customer can be expect who interest to expand this system etc… can be included to improve the
Ethio-matrimony platform. Also, if there are email validations and password reset using email
alert is one of great ways of we can make our system more secure. The final recommendation
towards the target group who need to work on and improving it can even think of what make

difference our system from other dating site on host by having addition feature like supporting
some local languages familiar with our country addition to common languages.
References
Bibliography
 Mall,Rajib(2009). Fundamentals of Software Engineering (3rd ed.). PHI Learning Private
Limited.
 Kahate, Atul (2004). Object Oriented Analysis and Design. Tata McGraw-Hill
Works Cited

AMU. (n.d.). amu. Retrieved March 2, 2016, from Amu website: www.amu.edu.et
Gulicha, S. (2004). Sosit Gulicha. Addis Abeba.

Final Project Matrimony Edited-Nu

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final Project Matrimony Edited-Nu

Uploaded by

Copyright:

Available Formats

ARBAMINCH UNIVERSITY

ARBAMINCH INSTITUTE OF TECHNOLOGY (AMiT)

GROUP MEMBER’S NAME AND ID NO

1. ASSEFA SENBATO RAMIT/1320/05

Advisor: Mr. Sajil.Surabhi Examiner: …………………

A Senior Project Report

Submitted to Department of Computer Science and IT, Arbaminch Institute of Technology,

Arba Minch University

Arba Minch Institute of Technology(AMiT)

This is to certify that the senior project titled “Ethio-Matrimony”, submitted by

Date: 31st May 2016

Final Year Project documentation Page ii

Final Year Project documentation Page iii

Matrimonial web sites or marriage websites are used as an alternative to the

Final Year Project documentation Page iv

Final Year Project documentation Page v

1.9.3 Analysis and Design Approach................................................................................................9

Final Year Project documentation Page vi

3.2.6 User Interface Prototyping.....................................................................................................56

Final Year Project documentation Page vii

Final Year Project documentation Page viii

Figure 40 Home page by English................................................................................................70

Table 1 Team Composition............................................................................................................2

Final Year Project documentation Page ix

1.1Background of Arbaminch University[CITATION AMU \l 1033 ]

1.1.1 Mission of AMIT

1.1.2 Vision of AMIT

Final Year Project documentation Page 1

Final Year Project documentation Page 2

1.5 Objective of the Project

1.5.1 General Objective

1.5.2 Specific Objective

Final Year Project documentation Page 3

Final Year Project documentation Page 4

10th Dec- 15th

15th May- 25th

28th Apr- 15th May

Start Time duration End

1.7 Scope and Significance of the Project

For Registered Member:

Final Year Project documentation Page 6

Final Year Project documentation Page 7

1.8 Target Beneficiaries of the System

1.9 Methodology for the Project

1.9.2 Fact Finding

Final Year Project documentation Page 8

1.9.5 Testing procedure

Final Year Project documentation Page 9

 More effective on larger units of code.

Final Year Project documentation Page 10

1.9.7 Limitation of the Project

1.9.8 Risk, Assumption and Constraint

Final Year Project documentation Page 11

2.1 Introduction of Existing System

Some defects in existing system are:

2.2Players in the Existing System

Final Year Project documentation Page 12

 More personal details of individuals

 Search bride or groom based on their inputs. May found or not.

2.5Report generated in the existing system

Final Year Project documentation Page 14

Figure 1 form of existing system