College of Electrical & Mechanical Engineering

Department of Software Engineering

Undergraduate Project Documentation

Title: Criminal Record System

Group Member:

No. Name ID
1. Denberu Esubalew ETS0322/09
2. Melak Nega ETS0755/08
3. Mikiyas Tibebu ETS0699/09
4. Yamlak Tesfaye ETS0994/09

Advisor Name: Aderaw Semma Signature: ____________________

3/11/2020
Acknowledgement
We would like to thank Salo Gora Gelan Police Station and Inspector Tezera for his unrestricted
support and knowledge. We also would like to reserve our utmost respect and gratitude to our
advisor Mr. Aderaw Semma for his contribution in directing us in the correct direction.

1
Contents
1. Chapter One: Introduction ----------------------------------------------------------------------------- 9
1.1. Background ----------------------------------------------------------------------------------------- 9
1.2. Problem Statement -------------------------------------------------------------------------------- 10
1.2.1. Existing System ------------------------------------------------------------------------------ 11
1.2.2. Problem of existing system----------------------------------------------------------------- 15
1.2.3. Proposed system ----------------------------------------------------------------------------- 15
1.2.4. Advantage of proposed system ------------------------------------------------------------ 15
1.3. Motivation ------------------------------------------------------------------------------------------ 16
1.4. Scope and Limitation ----------------------------------------------------------------------------- 16
1.4.1. Scope ------------------------------------------------------------------------------------------ 16
1.4.2. Limitation ------------------------------------------------------------------------------------- 17
1.5. Goals and Objectives ----------------------------------------------------------------------------- 17
1.5.1. Goals ------------------------------------------------------------------------------------------- 17
1.5.2. Objectives ------------------------------------------------------------------------------------- 17
1.6. Methodology --------------------------------------------------------------------------------------- 18
1.6.1. Methods --------------------------------------------------------------------------------------- 18
1.6.2. Requirement Gathering and Analysis ----------------------------------------------------- 18
1.6.3. Design and Architecture -------------------------------------------------------------------- 18
1.6.4. Implementation ------------------------------------------------------------------------------ 20
1.6.5. Project Schedule ----------------------------------------------------------------------------- 20
2. Chapter Two: System Requirement Specification ------------------------------------------------- 21
2.1. Introduction ---------------------------------------------------------------------------------------- 21
2.2. Functional Requirement -------------------------------------------------------------------------- 21
2.2.1. Criminal Information management ------------------------------------------------------- 21
2.2.2. Reporting-------------------------------------------------------------------------------------- 22
2.3. Non-Functional Requirement -------------------------------------------------------------------- 22
2.3.1. Performance requirement ------------------------------------------------------------------- 22
2.3.2. Security requirement ------------------------------------------------------------------------ 22
2.3.3. Safety requirement--------------------------------------------------------------------------- 23
2.3.4. Software quality attribute ------------------------------------------------------------------- 23

2
 2.4. Feasibility Study----------------------------------------------------------------------------------- 23
2.4.1. Operation feasibility ------------------------------------------------------------------------- 23
2.4.2. Technical feasibility ------------------------------------------------------------------------- 23
2.4.3. Economic feasibility------------------------------------------------------------------------- 23
3. Chapter Three: System Analysis and Modeling --------------------------------------------------- 24
3.1. Overview ------------------------------------------------------------------------------------------- 24
3.2. Scenario based modeling ------------------------------------------------------------------------- 24
3.2.1. Use case identification ---------------------------------------------------------------------- 24
3.2.2. Actor identification -------------------------------------------------------------------------- 24
3.2.3. Use case diagram ---------------------------------------------------------------------------- 25
3.2.4. Use case Description ------------------------------------------------------------------------ 26
3.2.5. Activity diagram ----------------------------------------------------------------------------- 33
3.3. Behavioral Modeling ----------------------------------------------------------------------------- 38
3.3.1. Sequence diagram --------------------------------------------------------------------------- 38
3.3.2. State diagram --------------------------------------------------------------------------------- 41
3.4. Class base modeling ------------------------------------------------------------------------------ 47
3.4.1. Class identification -------------------------------------------------------------------------- 47
3.4.2. Class diagram -------------------------------------------------------------------------------- 48
4. Chapter Four: System Design ------------------------------------------------------------------------ 49
4.1. Overview ------------------------------------------------------------------------------------------- 49
4.2. System Design ------------------------------------------------------------------------------------- 49
4.2.1. System decomposition ---------------------------------------------------------------------- 49
4.2.2. Module description -------------------------------------------------------------------------- 49
4.3. Architecture of the system ----------------------------------------------------------------------- 49
4.3.1. Architecture style and pattern -------------------------------------------------------------- 49
4.3.2. Component diagram ------------------------------------------------------------------------- 50
4.3.3. Deployment diagram ------------------------------------------------------------------------ 52
4.4. Database design ----------------------------------------------------------------------------------- 53
4.5. User interface design ----------------------------------------------------------------------------- 54
4.5.1. Login user interface design ----------------------------------------------------------------- 54
4.5.2. Home page user interface design ---------------------------------------------------------- 54

3
 4.5.3. Search information user interface design------------------------------------------------- 55
4.5.4. Generate report user interface design ----------------------------------------------------- 55
Reference and Appendix ------------------------------------------------------------------------------------ 56

4
Lists of Figures
Figure 1. Suspect information form------------------------------------------------------------------------ 12
Figure 2. Witness information form ----------------------------------------------------------------------- 13
Figure 3. Plaintiff/Suspect/Witness Testimony form --------------------------------------------------- 14
Figure 4.MVC model ---------------------------------------------------------------------------------------- 19
Figure 5. Three tier model ---------------------------------------------------------------------------------- 19
Figure 6.Project Schedule ----------------------------------------------------------------------------------- 20
Figure 7.Use case diagram ---------------------------------------------------------------------------------- 25
Figure 8. Initialize system activity diagram -------------------------------------------------------------- 33
Figure 9. Add user activity diagram ----------------------------------------------------------------------- 34
Figure 10.Login activity diagram -------------------------------------------------------------------------- 35
Figure 11. Add criminal case activity diagram----------------------------------------------------------- 36
Figure 12. Search criminal activity diagram ------------------------------------------------------------- 37
Figure 13.Register user sequence diagram --------------------------------------------------------------- 38
Figure 14.Login sequence diagram ------------------------------------------------------------------------ 39
Figure 15. Add case sequence diagram ------------------------------------------------------------------- 39
Figure 16. Generate report sequence diagram ------------------------------------------------------------ 40
Figure 17.Login state diagram ------------------------------------------------------------------------------ 41
Figure 18.Register state diagram --------------------------------------------------------------------------- 42
Figure 19.Add case state diagram -------------------------------------------------------------------------- 43
Figure 20.Search criminal state diagram ------------------------------------------------------------------ 44
Figure 21.Search case state diagram ----------------------------------------------------------------------- 45
Figure 22.Generate report state diagram ------------------------------------------------------------------ 46
Figure 23.Class diagram ------------------------------------------------------------------------------------- 48
Figure 24.MVC model --------------------------------------------------------------------------------------- 50
Figure 25.Component diagram ----------------------------------------------------------------------------- 51
Figure 26.Deployment diagram ---------------------------------------------------------------------------- 52
Figure 27.Database diagram -------------------------------------------------------------------------------- 53
Figure 28.Login UI design ---------------------------------------------------------------------------------- 54

5
List of Tables
Table 1. Crime category ------------------------------------------------------------------------------------- 10
Table 2.Project Schedule timeline ------------------------------------------------------------------------- 20
Table 3.Initialize system use case description ----------------------------------------------------------- 26
Table 4.Register user use case description---------------------------------------------------------------- 26
Table 5.Login use case description ------------------------------------------------------------------------ 27
Table 6. Log info use case description -------------------------------------------------------------------- 28
Table 7. Manage account use case description ----------------------------------------------------------- 28
Table 8. Manage user account use case description ----------------------------------------------------- 29
Table 9.Add criminal case use case description --------------------------------------------------------- 30
Table 10. Edit criminal case use case description ------------------------------------------------------- 30
Table 11. Search information use case description ------------------------------------------------------ 31
Table 12.Generate report use case description ----------------------------------------------------------- 31

6
List of Abbreviations, Symbols, Specialized Nomenclature
Admin – Administrator

PDF – Portable document format

SQL – Structured query language

7
Abstract
This system helps in managing criminal information on a web-based system. It works by converting the
information stored on a paper by policeman/woman into a digitized form by the help of a data encoder to
input the data to system. Criminal record system aims to improve the traditional way of paper based
criminal information management by creating a simple and robust platform which aid in registering,
searching, report generating. The general idea of a digitally managed criminal information system is to
make criminal cases easily accessible which could help trigger a digital transformation in which we could
analyze the information stored in the digital medium to help reduce crimes. It will also help police
departments have a digital back up of the information collected on criminals, witnesses, plaintiffs. Other
uses of the system could also be used to manage policeman/woman by tracking the cases that they are
assigned to and tracking the progresses they have made in solving their assigned crimes. The system will
also be able to generate monthly, quarterly and yearly reports which will help in determining the
performance, and the general metrics of a police department or a policeman/policewoman.

In the making of this project we have found that the current system is full of defects that inhibits the
effectiveness of crime prevention methods the police uses. Some of these problems are

• Managing criminal info

• Analyzing available information
• Data security; Data on paper is difficult to create a backup and could easily be damaged
Despite all these flaws police stations have remained using it for so long. The reason behind continuing to
use this much ineffective and flawed system is the knowledge the polices possess. Since using a digital
version of the current system requires a basic computer and language skill thus hindering the
implementation of the system.

The solution we found for this is assigning a data-encoder who is responsible for inserting provided
information to the computer.

አብስትራክት
ይህ ስርዓት የወንጀል መረጃዎችን በድር ላይ በተመሠረተ ስርዓት ለማስተዳደር ይረዳል፡፡ ስርዓቱ በወረቀት ላይ በፖሊስ
የተከማቸውን መረጃ በዲጂታዊ ቅርፅ በመረጃ ሰጭው መረጃ ወደ ስርዓቱ ለማስገባት በመለወጥ ይሠራል፡፡ የወንጀል
መዝገብ ስርዓት ዓላማው በወረቀት ላይ የተመሠረተ የወንጀል መረጃ አያያዝ ባህላዊ መንገድን ለማሻሻል ፣
ለማስመዝገብ ፣ ለመፈተሽ እና ሪፖርት ለማድረግ የሚረዳ ቀላል እና ጠንካራ መድረክን በመፍጠር ነው ፡፡ በዲጂታዊ
የወንጀል መረጃ ስርዓት አጠቃላይ ሀሳብ የወንጀል ጉዳዮችን ለመቀነስ ለማገዝ በዲጂታል መካከለኛ ውስጥ
የተከማቸውን መረጃ ለመተንተን የምንችልበትን የዲጂታል ለውጥ ለማምጣት የሚረዳ የወንጀል ጉዳዮችን በቀላሉ
ተደራሽ ማድረግ ነው፡፡ የፖሊስ መምሪያዎች በወንጀለኞች ፣በምስክሮች ፣በከሳሾች ላይ የተሰበሰበውን መረጃ
በዲጂታል እንዲደግፉ ይረዳቸዋል፡፡ ሌሎች የሥርዓቱ አጠቃቀሞችም የተመደቡባቸውን ጉዳዮች በመከታተል እና
የተመደቡትን ወንጀሎች በመፍታት ያከናወኗቸውን እድገቶች በመከታተል ፖሊስን ለማስተዳደር ሊያገለግሉ ይችላሉ፡
፡ አፈፃፀሙን ለመወሰን የሚረዱ ወርሃዊ፣ ሩብ ዓመታዊ እና ዓመታዊ ሪፖርቶችን እና የፖሊስ መምሪያን ወይም
የፖሊስ መኮንን አጠቃላይ ልኬቶችን ማዘጋጀት ይችላል፡፡

ይህንን ኘሮጀክት ሲያከናውን አሁን ያለው ስርዓት ፖሊሶች የሚጠቀሙባቸውን የወንጀል መከላከል ዘዴዎች
ውጤታማነት የሚገድቡ ጉድለቶች የተሞላ መሆኑን ተገንዝበናል፡ ፡ ከእነዚህ ችግሮች መካከል አንዳንዶቹ የሚከተሉት
ናቸው

• የወንጀል መረጃዎችን ማስተዳደር

• የሚገኘውን መረጃ መተንተን

8
• የመረጃ ደህንነት በወረቀት ላይ ያለ መረጃ ምትኬን ለመፍጠር አስቸጋሪ ስለሆነ በቀላሉ ሊጎዳ ይችላል

እነዚህ ሁሉጉድለቶች የፖሊስ ጣቢያዎች እስካሁን ድረስ ሲጠቀሙባቸው ቆይተዋል፡፡ ይህንን በጣም ውጤታማ ያልሆነ
እና ጉድለት ያለው ስርዓት መጠቀሙን ለመቀጠል የሚያስችለው ምክንያት ፖሊሶች የያዙት እውቀት ነው። የአሁኑ
ስርዓት ዲጂታል ሥሪት መጠቀም መሰረታዊ የኮምፒዩተር እና የቋንቋ ችሎታ ስለሚያስፈልግ የስርዓቱን አፈፃፀም
የሚያደናቅፍ ነው፡፡

ለእዚህ ያገኘነው መፍትሄ ለኮምፒዩተሩ የቀረበውን መረጃ የማስገባት ሀላፊነት ያለው የውሂብ-መሰየሚያ መሰየም
ነው፡፡

1. Chapter One: Introduction

1.1. Background
In 1913, during the reign of Emperor Menelik II, the Ethiopian police was founded for
the first time in our history. The police force was known as ‘’ Yeketema Zebegna” or
the City’s Guard. Just before the invasion of our country by Italy in 1963, City (Arada)
“Zebegna” (Guard) was founded to keep the security of the capital and this
establishment was well organized and suitable for the needs of the time. After the end
of the invasion, all government structures were abolished and new ones instituted by
Emperor Haile Selassie by royal decree No. 6/1934. A modern police establishment
was newly founded. The police force was governed by British citizens, according to
the book by Brigadier General Moges Beyene entitled “Police ena Gize” (Police at
Different Times) published in 1972.

After the downfall of the monarchic government in 1974, the military junta – the Derg
– that came to power enacted proclamation no. 10/1974 to provide for the nation’s
security and protection; however, no provision was incorporated therein regarding
organizational matters of the police. No separate proclamation of the police
establishment was enacted until the downfall of Derg in 1991.

After the downfall of Derg, it was found necessary to re-establish the police institution
for better organizational capabilities. In so doing, the police force has become in better
shape to discharge its duties of enforcing the constitution of the federal Democratic
Republic of Ethiopia and laws issued based upon that constitution; the police
establishment is also better suited to contribute its share to the nationwide activities of
development of a democratic system, to maintain peace and to expedite development.
The current police establishment, the Federal Police Commission, was founded
pursuant to proclamation no. 720/2004 based on the principles of non-partisanship,
impartial service to the society, commitment to policing ethics, competence and
quality of service.

There are three category of crime; light, medium, severe. In this category there are also
sub categories.

9
 Table 1. Crime category

Light Medium Severe

Threatening Cheque fraud Homicide

Defaming and Insult Document fraud Attempted murder

Assault Money forgery Robbery

Illegal weapon Illegal Drug use and Infrastructure theft

possession trafficking

Trespassing Scamming Rape

Lacking third party Illegal Weapon trafficking Car theft

insurance

Kidnapping Human trafficking

Computer fraud Terrorism

1.2. Problem Statement

It is the police force that is burdened with the responsibility of protecting lives and
property and assuring safety and well-being of all citizens through the detection and
apprehension of criminals, prevention and control of crime. Yet, there are still
problems, which arise from using a paper-based manual system that holds them back
in completing their mission properly. These are:

1. Poor criminal record keeping which makes the processing and retrieval of data
difficult.

2. Lack of good storage media which makes retrieval of data and information quite
stressful and bulky.

10
 3. Frequent case of missing files because records are not properly stored.

4. Time is wasted on simple tasks like looking for an information in previous cases,
organizing case files.

5. Wastes resource, completing a simple search or creating a report requires a lot of

workforce.

1.2.1. Existing System

In current criminal case management first, a plaintiff will report a case to a police
station then police will be assigned to solve the case. The assigned police start by
requesting the plaintiff’s personal information and then his testimony of the events
that occurred.
The next step will be identifying the witnesses in the crime and collecting their
personal information and their testimony after registering this information the police
will then identify or may conclude who the suspect is which will be called to the
police station to give his/her testimony and personal information. If the police feel
like he/she has identified the correct suspect the case will be sent to court for final
verdict which will judge if the suspect is guilty or innocent.
One thing we have to note is that all this information is stored on a paper.

11
Figure 1. Suspect information form

12
Figure 2. Witness information form

13
Figure 3. Plaintiff/Suspect/Witness Testimony form

14
1.2.2. Problem of existing system
A lot of problems exist in the manual system police currently uses.
• Generating a crime filing number for each of the crime that occurs is
difficult because it’s not easy to trace the file number of the last recorded
crime and this problem has led to the duplication of file number.
• Retrieving files related to a specific parameter is difficult because in order
to achieve this they would have to look through each file.
• Due to nature of paper they get outdated in a short time which has led to a
lot of missing case files.
• Difficult to generate reports. Timely based reports which are done on a
monthly, quarterly and yearly basis require a lot of resources, time and
personnel.
• Couldn’t be analyzed as the information is not digitally available. Since it
is difficult to analyze them it is hard to draw conclusions from already
available information.
• Time-consuming, Current paper-based system makes searching a tedious
task. A simple search could take hours to days to complete which makes a
time sensitive police work essentially impossible to complete in a given
time.

1.2.3. Proposed system

Our proposed system is a web-based information management system in which the
data encoder will convert the data that the police has collected into a digital,
searchable, accessible, and modifiable information.
And System will have a way that will allow data encoders to search a criminal using
image, name or crime category.

1.2.4. Advantage of proposed system

This project when completed and implemented, will have the following advantages
• Durable storage – since data is going to be stored digitally, problems that stem
from saving them on papers will be avoided. Thus, providing durable storage.
• Secure storage – crime information is highly sensitive data so user credentials
are to going to be encrypted and have a periodic backup.
• Generating report – all the hassle of going through a stack of papers every
time a report needs to be generated will be solved as it will only require a time-
frame input and a click to generate them.
• Easy retrieval of data – there was no way of retrieving data with specific
parameters as it will require going through the papers looking for those
parameters.
• Efficient use of resources – time and human-power will be used properly as
the previous tedious tasks will be easy to execute.
15
 • Data Analysis – big challenge for data analysis is the lack of data, so making
it digitally available paves the way to analyze the data available. This would
allow us to visualize the data to easily understand the data.

1.3. Motivation
The data that is essential for solving crime is already in the police hands but they are
not using it as they should have. They are sitting on a gold mine of information but
they are trying to mine the gold using spoon.

Even though the police are always trying to protect its citizens by devising new plans
to prevent a crime from happening and by working 24/7 to catch criminals, they aren’t
getting enough help from the current technological advancements which could have
armed them well in carrying out their duty efficiently.

We are determined to fill this gap they have. We want to give them the tool that is
essential to mine this gold, we want to give them the pickle axe for information mining
which is a digitalized system which will help them in analyzing, searching and
reporting their data.

By making their work easy and productive we want to see a society with less crime
and a safe environment for future generations.

1.4. Scope and Limitation

1.4.1. Scope
Case management
Add, remove, edit and search criminal cases and allow different police stations to
share cases with each other.

User management

Add, remove and modify police account, data encoder account and provide a way
to authenticate the correct credentials also checking who logged in when and their
actions.

Report generation

Generate reports based on the data that is in the system and categorize it into
monthly, quarterly and yearly reports.

16
 1.4.2. Limitation
Our system doesn’t include human resource management system in which system
admin would monitor the process of hiring different bodies of a police station like
data encoder, policeman / policewoman and other workers.

1.5. Goals and Objectives

1.5.1. Goals
The goal of this project is to pave a way to a more information-based crime
prevention tactics that is based on analysis and modern tools that make policing
easier.

We also hope that this project will give further motivation for other developers like
data miners and AI specialists to work on the digitalized crime information to
support the police in their expertise.

1.5.2. Objectives
1.5.2.1. General Objective
The Objective of this project is to design and implement a web-based criminal
recording management for the police.

1.5.2.2. Specific Objective

▪ Gathering and analyzing information from the police.
▪ Study on previously made systems regarding criminal recording systems.
▪ Selecting a suitable programming language for the system.
▪ Reducing redundancies and inconsistencies that stem from using the current
system.
▪ Enables them to use their time and resource properly as the system will
make their work easy to complete.
▪ Providing enough information that will enhance decision making of the
police.
▪ Providing a way for police to generate reports on a given time frame.
▪ To have a more secure information management system that would
withstand different natural and human conditions.
▪ Easily visualize the progress of a police stations and help pinpoint a specific
helpful information.

17
1.6. Methodology
1.6.1. Methods
We will be using iterative developmental approach in which we break down the
software development of a large application into smaller chunks. In iterative
development, feature code is designed, developed and tested in repeated cycles.
With each iteration, additional features can be designed, developed and tested until
there is a fully functional software application ready to be deployed to customers.

1.6.2. Requirement Gathering and Analysis

For requirement gathering we used

▪ Observation – In which we analyzed from our own personal experience how

the police work and how they should improve their system.

▪ Interview – In which we went to our nearby police stations to interview and

gather requirement. We have asked them different question that will give us
incite on how the existing case management system works. We have gone
to Salo Gora Gelan police station and also to Akaki Kality police command
center.

1.6.3. Design and Architecture

We will be using MVC (Model View Controller) for the logical architectural design
and Three tier for the physical architectural design.

18
 Figure 4.MVC model

Figure 5. Three tier model

19
 1.6.4. Implementation
The project will be implemented using Django for the backend and React.JS for the
front end. MySQL for the database.

We will also be using other tools that are useful for the implementation of the
project like

▪ Git
▪ GitHub
▪ VScode
▪ Selenium
▪ OpenCV
▪ OpenVision

1.6.5. Project Schedule

Figure 6.Project Schedule

Table 2.Project Schedule timeline

Timeline Action Remark

November 1 Project kickoff

November 5 – 20 Requirement Gathering Salo Gora Gelan Police

Station

20
November 21 – 29 Requirement Analysis Incudes communicating to the
advisor

December 3 Requirement Specification

document

December 4 – January 4 System Design Incudes communicating to the

advisor

January 15 System Design

Documentation

February 27 – May 23 Development Includes testing,

Implementation, and
Deployment testing

May 24 Final Release

2. Chapter Two: System Requirement Specification

2.1. Introduction
Criminal record system is a web-based criminal information management system that will
allow users to add, edit and search criminal information.

This document specifies the purpose, functional and non-functional requirements of the
system and the feasibility study.

2.2. Functional Requirement

2.2.1. Criminal Information management
2.2.1.1. Description and Priority
It allows users to perform activities such as adding, modifying, searching and
deleting criminal information.
It is the main function of the system so it has high priority.

2.2.1.2. Operations
Adding criminal information: includes adding details about the criminal such
as name, date of birth, address, place of work, photo, etc. After logging in and
clicking the appropriate link to create a case information, data encoder will be
presented with a form to enter the given data to the computer. Then proper input
validation is performed to check for data integrity and safety, if everything is

21
 correct it will be submitted to the server where further input validation takes
place and finally the submitted data will be saved to the database.

Modifying/Editing criminal information: users are allowed to edit existing

criminal information. When there will be a need for changing stored info or
adding new info to the system the system will provide edit option to insert the
new information they will be added to the existing system.

Searching criminal information: provides searching capabilities using finger

print, photos, criminal information, crime category. Aside from basic searching
mechanisms that use a combination of information to return a specific result, the
system also provides searching using photo and fingerprint. Face and fingerprint
matching will be done using OpenCV.

2.2.2. Reporting and Visualization

2.2.2.1. Description and Priority
Our system will generate monthly, quarterly and yearly reports about overall
criminal records which include different numerical information like the number
of cases which are closed or not, the number of crimes classified by category,
the number of criminals.

2.2.2.2. Operations
Generating Reports: generates reports based on user given time frame.

2.3. Non-Functional Requirement

2.3.1. Performance requirement
• Our system will run on any modern browsers that support ReactJS.
• Since Django will be used for the back-end processing the data will not take
a lot of time and because it’s highly scalable there won’t be a significant effect
when the data stored increases and the number of users grow.

2.3.2. Security requirement

• Django will be used to implement the system as it is highly secure
framework.
• It will have a robust user authentication which is already built into the
framework.

22
 • Passwords will be encrypted so in case they are found it’ll be impossible to
easily crack the hashes.
• The system will only run on modern browsers as supporting old systems will
create a high security risk.

2.3.3. Safety requirement

• To ensure data safety the system will have a periodic backup.
• There will be a log that records main activities of users, it’ll make it easy to
track suspicious activities.

2.3.4. Software quality attribute

• The system will be reusable, portable, easily maintainable, reliable, testable
and responsive.

2.4. Feasibility Study

2.4.1. Operation feasibility
During our requirement gathering we learned that policemen/policewomen have a
limited computer skill and language skills. So, we have decided to use a data encoder
to convert the paper-based information to computer.
This setup is feasible because police stations only need one data encoder that has basic
computer and language skill.

2.4.2. Technical feasibility

For the system to be functional police departments should at least have one working
computer that fulfills the non-functional performance requirement specified above
with an internet connection and as of our observation every police station already own
a proper computer.

2.4.3. Economic feasibility

As stated above because policemen/policewomen do not have sufficient skills to use
the system so if police stations don’t already have data encoders, they must hire at
least one data encoder.

23
3. Chapter Three: System Analysis and Modeling
3.1. Overview
In this chapter we elaborate the basic requirements gathered during requirement elicitation
using different requirement modeling techniques like,

▪ Use case Diagrams

▪ Activity Diagrams
▪ Sequence Diagrams
▪ State Diagrams
▪ Class Diagrams

3.2. Scenario based modeling

3.2.1. Use case identification
▪ Initialize system
▪ Manage User account
o Create account
o Delete account
o Change password
o Change username
▪ Log Info
▪ Manage account
o Login
o Logout
o Display incorrect login
o Change password
o Change username
▪ Add criminal case
▪ Edit criminal case
▪ Search info
▪ Generate report

3.2.2. Actor identification

▪ Administrator: Is the person that is responsible for the management of user
accounts which includes creating and modifying accounts.
▪ Data Encoder: Is the person that is responsible for inserting criminal
information to the system.
▪ Policeman/woman: Is the person that leads a case and has a responsibility of
checking that the information the data encoder inserted is correct.

24
3.2.3. Use case diagram

Figure 7.Use case diagram

25
 3.2.4. Use case Description

Table 3.Initialize system use case description

Use case Name: Initialize ID: UC-1 Priority: High

system

Actor: Admin

Description: The admin initializes the system for the first time.

Precondition: The system must never run before.

Postcondition: The system will run for the first time.

Course of Action:

1. The Actor will launch a web browser and will navigate to the domain of
the system.

2. The Actor will navigate to login.

3. Then the system redirects to the log-in page on which the admin log in
using the user name and password he/she just signed up with.

4. The Actor will log into account.

Exception: Invalid name and/or password

Table 4.Register user use case description

Use case Name: Register ID: UC-2 Priority: High

Actor: Admin

Description: The actor will create account.

Precondition: A valid and unique username.

Postcondition: The user will have a new account and can login to the system.

26
Course of Action:

1. The Actor will launch a web browser and will navigate to the domain of
the system.

2. The Actor will navigate to Dashboard.

3. The Actor will choose create account.

4. If the actor has chosen create account the actor will be redirected to create
account registration form and input information needed.

5. If an existing account has the same username as the inputted username

the system notifies the actor that the username is already used.

6. After the actor pass all this procedure if there is no error the operation is
successful.

7. The user account will be created and can login to the system.

Exception:

1. The account doesn’t exist

2. Already used username

Table 5.Login use case description

Use case Name: Login ID: UC-3 Priority: High

Actor: Admin, Data Encoder, Policeman/woman

Description: Actors will be able to login to the system.

Precondition: Accounts must be created by the admin to the users.

Postcondition: Actors will use the system.

Course of Action:

1. Actors navigate to login page.

2. Actors fill in username and password.
3. If the credentials are correct actors will be logged in.
4. If there is an error information will be displayed.

27
Exception:

1. Account is not created by admin.

2. Error credentials.

Table 6. Log info use case description

Use case Name: Log Info ID: UC-4 Priority: Medium

Actor: Admin

Description: Allows the actor to keep track of who at what time logged in to the system.

Precondition: The system must have users and the actor must be logged in.

Postcondition: The system will show the actor log information.

Course of Action:

1. The Actor will launch a web browser and will navigate to the domain of
the system.

2. The Actor will navigate to the log info section

3. The system will list the name of users that logged in recently with the
time which they did.

Exception: Actor is not logged in.

Table 7. Manage account use case description

Use case Name: Manage ID: UC-5 Priority: Medium

account

Actor: Admin, Data Encoder, Policeman/woman

Description: Allows the actor to manage, view, and change information about their own
account.

Precondition: The actor must be logged in.

28
Postcondition: Save the new account information.

Course of Action:

1. The Actor will launch a web browser and will navigate to the domain of
the system.
2. The actor will navigate to the account section
3. The actor will choose from different account management tools like
change username, change password and logout.
4. The system will execute the actor’s choice.

Exception: Actor is not logged in or the changed username is taken.

Table 8. Manage user account use case description

Use case Name: Manage User ID: UC-6 Priority: Medium

account

Actor: Admin

Description: Allows the admin to manage, view, and change information about users account.

Precondition: The admin must be logged in.

Postcondition: Save the new user account information.

Course of Action:

1. The Admin will launch a web browser and will navigate to the domain of
the system.
2. The admin will navigate to the user management account section.
3. The admin will see the list of users in the system.
4. The actor will choose from a user account and different account
management tools like change username, change password, delete user.
5. The system will execute the actor’s choice.
Exception: Admin is not logged in or the changed username is taken.

29
 Table 9.Add criminal case use case description

Use case Name: Add criminal ID: UC-7 Priority: High

case

Actor: Data Encoder

Description: Allows the actor to add criminal information as provided by the policeman.

Precondition: The actor must be logged in.

Postcondition: Save the new criminal information.

Course of Action:

1. The Actor will launch a web browser and will navigate to the domain of
the system.

2. The actor fills provided-form properly

3. Input verification takes place

4. Saves the given information if there is no error in the input verification

process.

Exception: Improper input in the form fields.

Table 10. Edit criminal case use case description

Use case Name: Edit criminal ID: UC-8 Priority: High

case

Actor: Data Encoder

Description: Customizes already existing criminal information.

Precondition: The actor must be logged in.

Postcondition: Save the new criminal information.

30
Course of Action:

1. The Actor will launch a web browser and will navigate to the domain of
the system.

2. Customizes the required information

3. Input verification takes place

4. Saves the given information if there is no error in the input verification

process.

Exception: Improper input in the form fields.

Table 11. Search information use case description

Use case Name: Search info ID: UC-9 Priority: High

Actor: Data Encoder, Policeman

Description: Allows the actor to add criminal information as provided by the policeman.

Precondition: The actor must be logged in.

Postcondition: Displays information returned after a search operation

Course of Action:

1. The Actor will launch a web browser and will navigate to the domain of
the system.
2. The actor provides search parameters
3. Given search parameters are run against a database
4. Displays info returned by the controller

Exception: No Exception

Table 12.Generate report use case description

Use case Name: Generate ID: UC-10 Priority: High

Report

31
Actor: Data Encoder

Description: system generates a report for a specified time frame

Precondition: The actor must be logged in.

Postcondition: generates pdf format of the returned info

Course of Action:

1. The Actor will launch a web browser and will navigate to the domain of
the system.
2. Specifies time frame.
3. Pdf format of the response in generated.
Exception: No Data available

32
3.2.5. Activity diagram
3.2.5.1. Initialize system activity diagram

Figure 8. Initialize system activity diagram

33
3.2.5.2. Add user activity diagram

Figure 9. Add user activity diagram

34
3.2.5.3. Login activity diagram

Figure 10.Login activity diagram

35
3.2.5.4. Add Criminal case activity diagram

Figure 11. Add criminal case activity diagram

36
3.2.5.5. Search criminal activity diagram

Dashboar
d
Figure 12. Search criminal activity diagram

37
3.3. Behavioral Modeling
3.3.1. Sequence diagram
3.3.1.1. Register user sequence diagram

Figure 13.Register user sequence diagram

38
3.3.1.2. Login sequence diagram

Figure 14.Login sequence diagram

3.3.1.3. Add case sequence diagram

Case added

Figure 15. Add case sequence diagram

39
3.3.1.4. Generate report sequence diagram

Figure 16. Generate report sequence diagram

40
3.3.2. State diagram
Login state diagram

Figure 17.Login state diagram

41
Register state diagram

Figure 18.Register state diagram

42
Add case state diagram

Figure 19.Add case state diagram

43
Search criminal state diagram

Figure 20.Search criminal state diagram

44
Search case state diagram

Figure 21.Search case state diagram

45
Generate report state diagram

Figure 22.Generate report state diagram

46
3.4. Class base modeling
3.4.1. Class identification
The classes that we identified are

▪ Admin
▪ Account
▪ Report
▪ Monthly report
▪ Quarterly report
▪ Yearly report
▪ Station
▪ Policeman/woman
▪ Data Encoder
▪ Case
▪ Criminal
▪ Work
▪ Person
▪ Living Address
▪ Witness
▪ Plaintiff

47
3.4.2. Class diagram

Figure 23.Class diagram

48
4. Chapter Four: System Design
4.1. Overview
Our system will be using MVC architecture having three tiers that means we will have a
model which is going to be built using Django framework, the view is going to be built
using React.JS library and the third tier which is the database is gone be built with MySQL.

4.2. System Design

4.2.1. System decomposition
These are included in the system decomposition

▪ User Management
▪ Search
▪ Case management
▪ Log
▪ Report
4.2.2. Module description
User Account Management

▪ Manages user creation, and modification of existing user info.

▪ Login/logout.

Reporting

▪ Generates a report based on the required time frame.

▪ Exports generated reports to PDF.

Search

▪ Encompasses basic search and Face search features.

▪ Basic search looks for keyword in the database entries.
▪ Advanced search uses the combination of the keywords and could also be
used to perform face matching on a given image/s

Case management

▪ Includes adding new case and modifying existing cases.

4.3. Architecture of the system

4.3.1. Architecture style and pattern
Since the system is to be built upon the Django web framework it will use Model
View Controller (MVC) architectural style. Models are the data portion of the
framework they will hold information about the criminals, police, witness, crimes
and cases. View contains information that will be sent to the users, they are the HTML

49
 parts. Controller is the server-side logic that will be applied to the given or retrieved
data.

Figure 24.MVC model

4.3.2. Component diagram

How different modules, components are built, organized and interact with each other.

We have identified these components in our system

▪ Manage User component

▪ Search component
▪ Report component
▪ Log component
▪ Criminal case component

50
Figure 25.Component diagram

51
4.3.3. Deployment diagram

Figure 26.Deployment diagram

52
4.4. Database design
The system will be using MySQL database which is a relational SQL based database.

Figure 27.Database diagram

53
4.5. User interface design
4.5.1. Login user interface design

Figure 28.Login UI design

4.5.2. Home page user interface design

Figure 29.Home page user interface design

54
4.5.3. Search information user interface design

Figure 30.Search information user interface design

4.5.4. Generate report user interface design

Figure 31.Generate report user interface design

55
Reference and Appendix
• The evolution of MVC and other UI architectures from Martin Fowler
http://martinfowler.com/eaaDev/uiArchs.html
• Davis, Ian. What are the benefits of MVC? http://blog.iandavis.com/2008/12/what-are-the-
benefits-of-mvc
• Deployment patterns ( Microsoft Enterprise Architecture, patterns and Practices)
http://msdn.microsoft.com/en-us/library/ms998478.aspx
• Fowler, Martin “Pattern of enterprise application architecture” (2002). Addison Wesley
• http://www.federalpolice.gov.et/web/guest/background-information

56
Interview Questions

1. How does the current criminal information management system work?

2. How many different types of crime categories are there?
3. What drawbacks do you think will inhibit a digital system in a police station?
4. What information do you collect from a suspect, plaintiff or a witness?
5. What kind of reports do you need and at what time do you need it?
6. What is the skill level of an average police?
7. How many types of report do you have and how do you generate report?

Interview Answers

1. The current criminal information management system work by collecting

witness, plaintiff and suspects testimonies on a paper including other important
documents related to the case.
2. There are around three categories of crime severe, medium, light. These also
have their own sub category like theft, rape, homicide …
3. The drawback will be technological abilities of the policeman/policewoman.
4. We usually use a form that has a list of personal information questions that
include Address, Name, birth date and place…
5. There are different types of reports that we use but we mainly have a monthly
report that specifies the data on monthly basis.
6. Average police have a high school level knowledge which is basic.
7. We have around three different type of report type monthly, quarterly and
yearly reports. We generate reports by using

57