ADDIS ABABA UNIVERSITY

SCHOOL OF GRADUATE STUDIES

COLLEGE OF NATURAL SCIENCES
DEPARTMENT OF COMPUTER SCIENCE

KEBELE MANAGEMENT SYSTEM

Prepared by:

NAME ID. NUMBER

1. AGAZI MEBRAHTOM GSR/1858/06

2. MAEREG ABREHA GSR/1876/06
3. MELAKU FISSE GSR/1877/06
4. NATNAEL ARGAW GSR/1878/06
5. SELAMAWIT ALEMU GSR/1879/06

Course Name: Object Oriented Software Development

Course Code: CoSc611

Requirement Analysis Document

Submitted to: Dida Midekso(PhD)

Nov, 2013

I
Contents
List of Figures ........................................................................................................................................ II
List of Tables ........................................................................................................................................ III
Acronyms .............................................................................................................................................. IV
1. Introduction ......................................................................................................................................... 1
1.1. Background.............................................................................................................................. 1
1.2 Statement of the problem.......................................................................................................... 2
1.3 Objectives of the project ............................................................................................................... 3
1.3.1 General Objectives ................................................................................................................. 3
1.3.2 Specific Objectives................................................................................................................. 3
1.3 Scope of the project ..................................................................................................................... 4
1.4 Proposed system ............................................................................................................................ 4
1.4.1 Functional Requirements ......................................................................................................... 4
1.4.2 Non-Functional Requirements ................................................................................................. 4
1.5 System models ............................................................................................................................... 6
1.5.1 Use case diagram .................................................................................................................... 6
1.5.2 Class diagram........................................................................................................................ 15
1.5.3 Sequence diagram ................................................................................................................. 16
1.5.4 User Interface Design ............................................................................................................ 23
References ......................................................................................................................................... 30

I
List of Figures
Figure 1.5.1 Use case diagram----------------------------------------------------------------------------6

Figure 1.5.2 Class Diagram---------------------------------------------------------------------------------------15

Figure 1.5.3.1 Sequence Diagram: Initiate Resident Registration-------------------------------------------16

Figure 1.5.3.2 Sequence Diagram: Confirm Applicant's Membership--------------------------------------17

Figure 1.5.3.3 Sequence Diagram: View Personal Information---------------------------------------------18

Figure 1.5.3.4 Sequence Diagram: Initiate Clearance Request---------------------------------------------19

Figure 1.5.3.5 Sequence Diagram: Renew ID Card----------------------------------------------------------20

Figure 1.5.3.6 Sequence Diagram: Register House----------------------------------------------------------21

Figure 1.5.4.1 The Main Window-------------------------------------------------------------------------------22

Figure 1.5.4.2 The Login Page--------------------------------------------------------------------------------- -23

Figure 1.5.4.3 Administrator main Page-----------------------------------------------------------------------24

Figure 1.5.4.4 Data Encoder Main Page-----------------------------------------------------------------------25

Figure 1.5.4.5 View Personal Information Page--------------------------------------------------------------25

Figure 1.5.4.6 House Registration Page-----------------------------------------------------------------------26

Figure 1.5.4.7 Membership Confirmation Page-------------------------------------------------- -----------27

Figure 1.5.4.8 Sample ID Card To be Issued-------------------------------------------------------- --------27

Figure 1.5.4.9 Sample Error Messages-----------------------------------------------------------------------28

Figure 1.5.4.10 Error While Members Register------------------------------------------------------------28

II
List of Tables
Table 1.5.1.1 Use Case, View Personal Information---------------------------------------------------7

Table 1.5.1.2 Use Case, Request marriage Certificate------------------------------------------------8

Table 1.5.1.3 Use Case, Initiate Clearance Request----------------------------------------------------9

Table 1.5.1.4 Use Case, Initiate Registration ----------------------------------------------------------10

Table 1.5.1.5 Use Case, Register House----------------------------------------------------------------11

Table 1.5.1.6 Use Case, Confirm Applicants Membership--------------------------------------- 12

Table 1.5.1.7 Use Case, Renew ID card----------------------------------------------------------------13

Table 1.5.1.8 Use Case, Generate Report--------------------------------------------------------------14

Table 1.5.1.9 Use Case, Issue Permanent ID Card----------------------------------------------------14

III
Acronyms
 ID - Identification Card
 Reg - Registration
 Ctrl - control
 Ack - Acknowledgement
 Mem - Member
 Temp- Temporary
 FIFO- First in First out

IV
1. Introduction
1.1. Background
Due to its numerous benefits, Computer technology has been applied to the automation of office
tasks and procedures. Much of the technology is aimed not only at improving the efficiency of
current office procedures, but at altering the nature of office works altogether. A broad definition
of office automation may include all use of computer technology to support the "knowledge
worker"; this definition includes computer-aided graphics and design tools, decision support
systems, and any use of personal computers for work-related tasks. [1]

In this project, a more narrow view of office automation has been taken, concentrating on the
administrative component of an organization's functioning. Among the numerous areas of
applications of computers we are going to apply for solving a challenge of a nation, developing
Kebele management system.

A kebele (Amharic "neighbourhood") is the smallest administrative unit of Ethiopia similar to a

ward, a neighbourhood or a localized and delimited group of people. It is part of a woreda, or
district, itself usually part of a Zone, which in turn are grouped into one of the Regions based on
ethno-linguistic communities (or kililoch) that comprise the Federal Democratic Republic of
Ethiopia. Each kebele consists of at least five hundred families, or the equivalent of 3,500 to
4,000 persons. There is at least one in every town with more than 2,000 populations. A keftanya,
or representative, had jurisdiction over six to twelve kebele's.[ 2]

The kebele's do not enjoy the same constitutional formality as regions, zones and woreda, but are
in effect the prime contact level for most Ethiopian citizens. kebele administrations consist of an
elected kebele council, a kebele cabinet, a social court and the development and security staff
posted in the kebele. The kebele cabinet usually comprises a manager, chair person development
agents, school director, representatives from women and youth association. Generally, the kebele
council main responsibilities are preparing an annual kebele development plan, Registering and
validating residents in the domain, Manipulating Shelter related information in the domain,
ensuring a collection of land and agricultural income tax and Resolving conflicts within the
community. [3]
However, this project mainly focuses on the design and implementation of kebele management
system regarding to Registration & validation of residents profile.

1
1.2 Statement of the problem

After the decentralization of power in recent, the delivery of the most common public services
has been channelled to the lower administrative levels of government organization. Services like
issuance of marriage certificates, land rent/taxes, conflict management and security services and
Issuance of ID cards etc., makes differences from the past. That means they are now
decentralized to lower administrative levels, such as Kebele’s, which are more numerous and
closer to the society that needs these services.
Despite its attractiveness and potential for improvement, however, decentralization is not without
problems. Bringing all such services mentioned above from few centralized and well-staffed or
well-organized administrative centres down to the numerous and relatively less-staffed kebele
centres had to come about at a real cost. Apart from the resulting financial implication due to the
personnel and running overheads of the Kebele offices, establishing an up-to-date filing,
documentation and data management system has been expensive and extremely difficult for most
part. This has led to serious problems and negative implications.
Among the problems in this regard there has been the problem related to Issuance of ID cards.
This poses tremendous difficulties due to loss and/or misplacement of Personal files. Moreover,
cross-checking and verification as to whether an individual is resident of the kebele or the length
of residency to check if the individual is eligible for ID issuance or not is difficult due to the
poor and disorganized filing system.
The second problem is Data confidentiality problem. For instance, there is a probability for a
customer to register two times or more as a resident. Resident data handling is based on the
number of houses. As a good approach a person who registered in one Kebele cannot apply
again by the same house number. But, if he changes location or house number, he may get a
chance for another ID .There is no cross sectional data validation mechanism. Simply, the system
uses eye witnesses to certify the resident. This situation may pave the way for some illegal
activities like terrorism. The project should fill this gap by specifying some integrity rules on the
system data base.
In addition, the system is not cost effective and efficient. It takes a lot of time, paper and other
instruments to handle a full information of a resident.
Therefore, this project try to get adequate solution to the afore-mentioned problems through
designing a new computerized information management system.

2
1.3 Objectives of the project
The general and specific objectives of the study are the following.

1.3.1 General Objectives

The general objective of this project is to develop a kebele management .

1.3.2 Specific Objectives

To achieve the above general objective the following specific objectives are set to be completed.

Study the current system

Suggest possible solutions
Selecting the best solution
Designing the system with appropriate methodologies and tools
Developing a database that will be used by the system
Implement and Test the system using a chosen programming language and paradigm.

3
1.3 Scope of the project
This project mainly focuses on the manipulation of resident profile beginning from their
registration as a resident and Authentication to issuance of Clearance and other certificates as per
their request.

1.4 Proposed system

1.4.1 Functional Requirements
The functional requirements are functions or features that the system must include to satisfy the
system need and to be acceptable by the user.
The developed system is expected to provide the following functionalities:
The system should be able to Create and manage accounts for system administrators.
The system should be able to allow customers to initiate service requests.
The system should be able to Register Resident personal information.
The system should be able to Register House information.
System should be able to Process each and every resident requests based on the policy of
the organization.
The system should be able to Generate Timely Reports.

1.4.2 Non-Functional Requirements

Non-functional requirements of the system are requirements that are not directly related to the
functional aspect of the system. Instead, they describe user-visible features of the system.
The non-functional requirements of this system include features such as security, maintainability
and expandability, user friendliness, reliability and portability.

1.4.2.1 Security
Security is one of the important features of any computerized system. In this project, due
attention is given to the security of the administration part of the system. Hence, administrators
are required to enter valid credential in order to access the system for inserting, editing and
deleting information regarding the shopping centers.
1.4.2.2 Maintainability and Expandability
The system should be designed in such a way that it can be easily maintained by the system
developer or any authorized professional. Moreover, the system should be flexible enough to
accommodate the future needs of expansion of the shopping center.

4
1.4.2.3 User Friendliness
The consistent user interfaces to be developed will help the system to be user friendly. For this
reason, the interfaces and components of the interfaces should be designed in a user friendly
fashion to help users interact easily with the system.

1.4.2.4 Reliability and Efficiency

The system should respond to requests in a reasonable period of time, i.e. at least before
the session expires. Moreover, it should give only valid result, if no data is found with the
specified criteria the system should not have to crash or give invalid response.

1.4.2.5 Portability
The system should be designed in such a way that it can be used in different plat forms.

5
1.5 System models
1.5.1 Use case diagram

Request Marrage
certificate

Initiate clearance
request

View personal
Information
Resident

Initiate <<include>>
Registration

<<include>>

<<include>>

Applicant <<extends>> Give temorary Id

confirm Applicants card
Membership

<<include>>

Register House
<<include>>

<<include>> Login

Renew Id card
Data Encoder
<<include>>

<<include>>

Generate Report
<<include>>

<<include>>

Issue clearance

Issue Merrage
certificate
Administrator

<<extends>>
Issue permanent ID Validate Resident
card

Figure 1.5.1 Use Case Diagram

6
1.5.1.1 USECASE DESCRIPTON
The system has four actors.
 Data Encoder: The Data Encoder manages registration of the population, registration
house, generate report and conform member ship request by issuing temporary ID card.
 Administrator: The administrator gives Permanent ID card, Confirms Clearance and
Certificate Request, and generates report.
 Resident: The Resident acts by initiating requests related to membership, Clearance and
Certificate.
 Applicant-A person who interacts with the system for the first time to initiate
Registration.

1.5.1.1.1 Use Case: View Personal Information

UC1. View Personal Information
Participating Actor Resident/Customer
Description Allows the resident to see updates and announcements
Pre condition The Resident should log in to the system.
Flow of events 1. The Resident Activates Log in Page
2. The Resident completes and submits the log inform self
(Alternative Course A:Blank Field ,Alternative Course B: The
user Did not sign up Before)
3. The system displays Resident home page
4. The use case ends
Alternative Course A:Blank A2. The system displays error message
A.3 The Log in Page Displayed
Field
A4. The use case ends
Alternate case B The user Did B3. The system displays error message
B4. The signup form Displayed
not sign up Before
B5. The use case ends

Post condition The Resident main Page Displayed.

Table 1.5.1.1.1 Use Case: View Personal Information

7
 1.5.1.1.2 Request marriage Certificate
UC2. Request marriage Certificate
Participating Actor Resident/Customer
Pre condition The Resident should log in to the system as a permanent resident.
Flow of events 1.The Resident Activates Log in Page
2. The Resident completes and submits the log in form (Alternative
Course A:Blank Field)
3. The system displays Resident home page
4. The Resident Activates the Marriage Certificate Requesting
Button
5.The System orders the request for further processing
6. The System Generates A delivery Report.
7. The use case ends
Alternative Course A2. The system displays error message
A.3 The Log in Page Displayed
A:Blank Field
A4. The use case ends
Post condition Marriage certificate Request Ordered and Delivery report sent back
to the applicant.
Table 1.5.1.1.2 Request marriage Certificate

8
 1.5.1.1.3 Use Case: Initiate Clearance Request
UC3. Initiate Clearance Request
Participating Actor Resident/Customer
Pre condition The Resident should log in to the system as a permanent resident.
Flow of events 1.The Resident Activates Log in Page
2. The Resident completes and submits the log in form (Alternative
Course A:Blank Field)
3. The system displays Resident home page
4. The Resident Activates Clearance Requesting Button
5.The System orders the request for further processing
6. The System Generates A delivery Report.
7. The use case ends

Alternative Course A2. The system displays error message

A.3 The Log in Page Displayed
A:Blank Field
A4. The use case ends
Post condition Clearance Request Ordered and Delivery report sent back to the
applicant.
Table 1.5.1.1.3 Use Case: Initiate Clearance Request

9
1.5.1.1.4. Initiate Registration
Participating Actor
Pre condition
Flow of events
Alternate Course A
Alternate Course B
Post condition
Table 1.5.1.1.4 Initiate Registration
UC4. Initiate Registration
Resident/Customer
The Resident should log in to the system.
1. The Resident activates “member ship sign up” form
2. The Resident completes and submits the member ship sign up
for providing detail information about him/her self (Alternative
Course A: Already Registered B:Blank Field)
3. The system registers the Resident
4. The system displays acknowledgment message
5. The use case ends
A.2 The system displays error message
A.3 The use case ends
B.2 The system displays error message
B.3 The use case ends
Member ship Request Ordered and Delivery report sent back to
the applicant..
10
1.5.1.1.5. Use Case: Register House
UC5: Register House
Participating Actor Data Encoder
Pre condition The Data Encoder should log in to the system.
Flow of events 1. The Data Encoder Activates House Register Button
2. The system displays house Registration form
3. The Data Encoder inserts necessary data to the form
4. The system updates house list(Alternative Course A: Invalid
Input )
5. The system displays successfully saved message
6. The use case ends
Alternate Course A A.4 The system displays error message
A.5 The system displays house Registration form
A.6 The use case ends
Post condition House Registered.

Table 1.5.1.1.5 Use Case: Register House

11
 1.5.1.1.6. Confirm Applicants Membership
Participating Actor
Pre condition
Flow of events
Alternate Course A
UC6: Confirm Applicants Membership
Data Encoder
The Data Encoder should log in to the system.
1. The Data Encoder opens member ship confirmation page
2. The System Extracts the requests and Display in the page in FIFO
order
3. The Data Encoder Validate the Applicant(Alternative Course A: not
eligible )
4. The Data Encoder confirms the applicant
5. The system Accepts a confirmation message from the data encoder
on a specific profile
6. The system Prepares and prints Temporary ID Card
7. .The Use Case Ends.
A.3 The data encoder eject the user profile
A.4 The system sends failure message to the applicant
A5. The system Displays the next applicant profile
A.6 The use case Ends

Post condition Temporary ID Card Issued.

Table 1.5.1.1.6: Use Case, Confirm Applicants Membership

12
 1.5 1.1.7. Renew ID card
Participating Actor
Pre condition
Flow of events
Alternate Course A
UC7: Renew ID card
Data Encoder
The Data Encoder should log in to the system.
1. The data encoder activate Renew Id card button
2. the system displays renew id page
3. the data encoder inserts applicants id number
4. The system verifies resident
5. The system Display applicants profile
6.The data encoder updates profile(Alternative Course A: Not eligible for Renewal)
7. The system prints a renewed id card
8. The system Displays the next applicant profile
9. The use case ends
A.6 The Residents ID does not exist message displayed
A.7 The system Displays the next applicant profile
A.8 The use case ends

Post condition ID Card renewed.

Table 1.5.1.1.7: Use Case, Renew ID card

13
1.5.1.1.8. Generate Report
Participating Actor
Pre condition
Flow of events
UC8: Generate Report
Administrator, Data Encoder
The Administrator/ Data Encoder should log in to the system.
1. The Data clerk, Administrator activates the generate report
button
2. The system responds by presenting a form. (NB: The form
includes a report type, time etc specifications
3. The Administrator/ Data Encoder specifies the report concern
4. The system generates the report.
5. The use case ends.

Post condition Report Generated.

Table 1.5.1.1.8 Use Case, Generate Report

1.5.1.1.9. Issue Permanent ID Card

UC 9: Issue Permanent ID Card
Participating Actor Administrator
Pre condition The Administrator should log in to the system.
Flow of events 1. The Administrator Activates Issue ID card Button
2. The System Extracts the profile of eligible residents for
permanent ID Issuance) and Displays in FIFO order (NB.
Eligibility determined on how long they stay in that kebele after
their first application
3. The Administrator confirms the applicants
4. The system Accepts a confirmation message from the
administrator on a specific profile
5.The system Prepares and prints Permanent ID Card
6. The Use Case Ends.
Post condition ID Card Issued.

Table 1.5.1.9: Use Case, Issue Permanent ID Card

14
 1.5.2 Class diagram
Class diagrams describe the structure of the system in terms of classes and objects. Classes are
abstractions that specify the attributes and behavior of a set of objects where as objects are
entities that encapsulate state and behavior [4].
In Figure 1.5.2, the class diagram for the system shows the classes with their potential attributes
and methods.

0..1
Marriage certificate
-Subject : string
-Statement : string
Applicant -Date Of Issuancel : Date 1
-Applicant No : int +Request() : void
-First Name : char +Issue() : void
-Middle Name : char
-Last Name : char
-sex : char 1
-profile picture : object(idl)
-Date of birth : Date
Permanent Resident
-House Number : int
-Phone Number : String 1 -Resident Id : string
-Date of Application : Date -JOb title : char 1
-Application status : char -Mothers Name : char
-background : char -marital status : char
-Nationality : char -place of birth : char
+Register() : void -Nationality : char
+Update() : void -date of reg : Date
+Register() : void
+Update() : void 1
+Remove() : void
+count() : int
0..1 +Search() : void Id Card
-Resident Id : int
-Date of registration : Date
Clearance 1..*
1 -callee : char
-Subject : string #Issue() : void
-Statement : string #Renew() : void
-Date Of withdrawal : Date +Delete() : void
+Issue() : void
+Request() : void
1

1
1..*
1
House
-House number : int
-Area in caremeter : long Account
-Date of Registration : Date -User Name : string
+Register() : void -Password : string
+Search() : void -privillage : char
+Update() : void +Create() : void
+Delete() : void +Update() : void
+Delete() : void

Figure 1.5.2 Class Diagram

15
 1.5.3 Sequence diagram
A sequence diagram ties use case with objects. It shows the interaction between
participating objects in a given use case. It is helpful to identify the missing objects that
are not identified in the analysis object model. From the use case and the class
diagrams shown in the previous section the sequence diagrams of the system is shown
as follows.

16
 Actor Member Reg
Reg Button Reg Ctrl Reg Form Acknowledgement
<<Applicantt>> table

press ()

Create ()

Create ()

X complete ()
l
l
submit ()

l Validate ()

Submit ()

X
Register ()

Create ()
X
View Ack () Submit Ack ()

X X X
Figure 1.5.3.1 Sequence Diagram: Initiate Resident Registration

17
 Actor Confirm Mem Confirm Mem Confirm member Temp mem
Member list Temp Id
<<Data Encoder>> Button ctrl form table

press ()

Create ()

create ()

X Get list
l

l
Fill Info
X
l
Validate () l
l

Confirm ()
l
l
Submit ()

X Register ()

create () X
Print () Submit ()

X X X

Figure 1.5.3.2 Sequence Diagram: Confirm Applicant's Membership

18
 Actor LoginForm Account table
Home Button Login Button Login ctrl Resident page
<<Resident>>

press ()

press ()

create ()

X create ()

Xfill () l
l
submit ()
l
Verify ()
l
Submit ()

X
Verify ()

create () X
View () Submit ()

X X X

Figure 1.5.3.3 Sequence Diagram: View Personal Information

19
 Actor Clearance Req clearance Req Clearance Req Clearance Req
Acknowledgment
<<Resident>> Button ctrl form order table

press ()

Create ()

create ()

X fill complete()
l
l
submit ()

l Validate ()
submit ()

X
Register ()

Create () X
View () Submit Ack ()

X X X
Figure 1.5.3.4 Sequence Diagram: Initiate Clearance Request

20
 Actor Renew Id card Renew Id Renew id
Id renew Form Id card
<<data encoder>> Button ctrl table

press ()

create ()

create ()

X fill Id() l

l
submit

get info ()

Verify ()
l
l

l
fill()

l
modify Form()
l
l
submit ()

X
update ()

create () X

Print () submit ()

X X X
Figure 1.5.3.5 Sequence Diagram: Renew ID Card

21
 Actor Reg house Reg House Reg house House list
Acknowledgement
<<data encoder>> Button ctrl form table

press ()

create ()

create ()
X
l
complete () l

submit ()

l Validate ()
submit ()

X
Register ()

create ()
X
View Ack () Submit ()

X X X
Figure 1.5.3.6 Sequence Diagram: Register House

22
 1.5.4 User Interface Design

1.5.4.1 The Main Window

The main window interface provides the user an option to Login, apply for membership, Check
Application Status and see General Information about the organization.

Figure 1.5.4.1 The Main Window

23
1.5.4.2 The Login Page
This page lets the user to Log in to the system using different privileges provided.

Figure 1.5.4.2 The Login Page

24
1.5.4.3 Administrator main Page
This page lets the user to issue ID Card,Certificate,Clearance and Generate Report.

Figure 1.5.4.3 Administrator main Page

25
1.5.4.4 Data Encoder Main Page
This page lets the user to Confirm applicants membership,Renew ID,Register House and Generate
Report.

Figure 1.5.4.4 Data Encoder Main Page

1.5.4.5 View Personal Information Page

This Page lets the resident to see his/her personal Information

Figure 1.5.4.5 View Personal Information Page

26
1.5.4.6 House Registration Page
Lets the Data Encoder to Register House.

Figure 1.5.4.6 House Registration Page

27
1.5.4.7 Membership Confirmation Page
Lets the Data Encoder to Confirm Members.

Figure 1.5.4.7 Membership Confirmation Page

1.5.4.8 Sample ID Card To be Issued

Figure 1.5.4.8 Sample ID Card To be Issued

28
1.5.4.9 Sample Error Messages
Error While Logging

Figure 1.5.4.9 Sample Error Messages

1.5.4.10 Error While Members Register

Figure 1.5.4.10 Error While Members Register

29
References
[1 ]. Margrethe H. Olson and Henry C. Lucas Jr. New York University

[2 ]. Population and Health in Developing Countries: Population, Health and Survival at INDEPTH
Sites. ISBN 0-88936-948-8

[3]. Serdar Yilmaz and Varsha Venugopal, (2008),International studies program, Local Goverment
Disrection and Accountability in Ethiopia

[4]. Reggie Davidrajuh, Java Bluetooth Wireless Technology for Evaluating Student Performance in
Classroom, University of Stavanger, 2005 Volume 5 Issue 4

30