See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/333262980

Final Project Report for the Law-Enforcement Management System

Article · October 2018

CITATIONS READS
0 3,258

1 author:

Alvin Chesaro
University of Nairobi
1 PUBLICATION   0 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

A Law-Enforcement Information Management System View project

All content following this page was uploaded by Alvin Chesaro on 22 May 2019.

The user has requested enhancement of the downloaded file.

 UNIVERSITY OF NAIROBI
COLLEGE OF BIOLOGICAL AND PHYSICAL SCIENCES
SCHOOL OF COMPUTING AND INFORMATICS

PROJECT REPORT
CRIMECLE: A LAW-ENFORCEMENT RECORDS
MANAGEMENT SYSTEM

ALVIN MWANGI CHESARO

P15/39225/2011

SUPERVISOR
DR. SAMUEL N. RUHIU

A project report submitted in partial fulfillment of the requirements for the award of Bachelor of
Science in Computer Science of the University of Nairobi
October 2018

1
 DECLARATION

I declare that this project is my original work, and to the best of my knowledge, has not been
presented by anyone for academic purposes in any university, hence all rights reserved
thereupon.

Signature: ______________________________ Date: ________________

Name: Alvin Mwangi Chesaro

Reg No: P15/39225/2011

This project report has been submitted in partial fulfillment of the requirements for the Bachelor
of Science in Computer Science with my approval as the Project Supervisor

Signature: ________________________________ Date: _______________

Name: Dr. Samuel N. Ruhiu

School of Computing and Informatics

2
 ACKNOWLEGEMENTS

My foremost and deepest gratitude goes to God to whom belongs all the glory, who qualified me
to undertake this project, for his abundant grace, care, mercy, guidance and protection from start
to finish.
My appreciation also goes all persons who in one way or another contributed towards the
successful completion of this project.
First to my supervisor Dr. Samuel N. Ruhiu who believed in the project and assisted in every
way possible, by connecting me to key users, providing support, encouragement, timely guidance
and suggestions throughout the duration of the undertaking of this project.
Second, to my loving mother and the rest of my family, whose moral, financial and spiritual
support served to motivate me and to keep giving my best.
Third, to the Director, School of Computing an Informatics, Dr. Agnes N. Wausi who believed in
me and afforded me a chance that was invaluable.
Fourth, to Mr. Albert K. Chesaro who generously lent his time and programming expertise to
help change the quality of the final product for the better.
Finally, to the police officers at the Kileleshwa as well as the Nairobi Central police stations who
cooperated and provided vital information that informed the structure of the system. May the
Lord’s blessings abound in your lives.

3
 ABSTRACT

The purpose and essence of any Records Management system is the right information in the right
place in the right order, at the right time for the right person at the lowest cost (Baje, 1998). This
can be achieved by an integrated, highly efficient and effective records management system.
With this in mind, a careful analysis of the records management method being utilized by the
Kenya Police Service(KPS) Nairobi Central station was conducted.
The findings showed that the manual system in place was highly inefficient- especially as far as
retrieval of archival patient information was concerned. This analysis established the need for a
Records Management System (RMS) that would facilitate effective and reliable records
management through automated processes and served as the basis for the research leading to the
development of such an RMS.
The Major objective of the project was to design and develop an RMS that would automate law
enforcement records management and directly benefit the KPS station in terms of fast
information retrieval, enhanced decision-making (crime statistics) whilst avoiding any confusion
that would jeopardize the quality of service delivery to civilians.
The RMS was designed as a client/server desktop application system and implemented using
Microsoft-based solutions that include Microsoft SQL as the database, and C# and the Extensible
Application Markup Language (XAML) as the programming languages.
The system was developed using the Spiral Development methodology. An extensive evaluation
of the project determined that the project achieved many of its predefined objectives however,
the major limitation of the project was the scope covered. From a proper analysis and assessment
of the designed system, it can be concluded that the system developed is an efficient, usable and
reliable records management system.

4
 TABLE OF CONTENTS

DECLARATION .......................................................................................................................................... 2
ACKNOWLEGEMENTS ............................................................................................................................. 3
ABSTRACT.................................................................................................................................................. 4
TABLE OF FIGURES .................................................................................................................................. 7
LIST OF TABLES ........................................................................................................................................ 9
LIST OF ACRONYMS AND ABBREVIATIONS .................................................................................... 10
CHAPTER 1: INTRODUCTION ............................................................................................................... 11
1.1 Background ............................................................................................................................... 11
1.2 Problem Definition .................................................................................................................... 12
1.3 Goal ............................................................................................................................................ 12
1.3 Project Objectives ..................................................................................................................... 13
1.3.1 Research Objectives ............................................................................................................ 13
1.3.2 Information System Development Objectives .................................................................... 13
1.4 Project Justification .................................................................................................................. 13
1.4.1 Service Delivery.................................................................................................................. 13
1.4.2 Automation ......................................................................................................................... 13
1.4.3 Data Integrity ...................................................................................................................... 14
1.4.4 Decision Making ................................................................................................................. 14
1.4.5 Data Security ....................................................................................................................... 14
1.5 Project Scope ............................................................................................................................. 15
CHAPTER 2: LITERATURE REVIEW .................................................................................................... 16
2.1 Introduction ............................................................................................................................... 16
2.2 Records Management Systems ................................................................................................ 16
2.3 The Kenya Police....................................................................................................................... 17
2.3 Current Solutions ...................................................................................................................... 19
2.3.1 CIS Records Management System ...................................................................................... 19
2.3.2 Polisys ................................................................................................................................. 19
2.3.3 Coplink................................................................................................................................ 20
2.3.4 CrimeStar ............................................................................................................................ 20
2.3.5 eFORCE Software Suite ..................................................................................................... 20
2.3.6 Directorate of Command, Control and Communication (IC3) Centre ................................ 21

5
 2.4 Gap Identified.................................................................................................................................. 21
CHAPTER 3: METHODOLOGY .............................................................................................................. 22
3.1 System Development Methodology.......................................................................................... 22
3.1.1 Spiral Development Model ................................................................................................. 22
3.1.2 Justification for the Use of the Model ................................................................................. 23
3.3. System Analysis ......................................................................................................................... 24
3.3.1 Feasibility Study ................................................................................................................. 24
3.3.1 Requirements Elicitation ..................................................................................................... 26
3.3.2 Proposed System ................................................................................................................. 28
3.3.3 Data Modelling ................................................................................................................... 29
3.3.1 Requirements Specification ................................................................................................ 35
3.4 System Design ............................................................................................................................ 38
3.4.1 Architecture Design ............................................................................................................ 38
3.4.2 Database Design.................................................................................................................. 40
3.3.2 User Interface Design.......................................................................................................... 47
CHAPTER 4: SYSTEM IMPLEMENTATION ......................................................................................... 51
4.1 Overview .......................................................................................................................................... 51
4.2 Software Requirements .................................................................................................................. 51
4.3 Hardware requirements ................................................................................................................. 53
4.4 System Testing................................................................................................................................ 53
CHAPTER 5: CONCLUSION.................................................................................................................... 55
5.1 Summary of Achievements ....................................................................................................... 55
5.2 Constraints................................................................................................................................. 55
5.3 Conclusion ................................................................................................................................. 55
5.4 Recommendations for Further Work ..................................................................................... 56
REFERENCES ........................................................................................................................................... 57
APPENDICES ............................................................................................................................................ 60
APPENDIX A: USER AND TECHNICAL MANUAL ..................................................................... 60
APPENDIX B: SAMPLE CODE ......................................................................................................... 66
APPENDIX C: SAMPLE INTERVIEW QUESTIONS .................................................................... 68

6
 TABLE OF FIGURES

Figure 1: The spiral development methodology (Boehm, 1988) ................................................. 23

Figure 2: Schedule Feasibility Diagram ....................................................................................... 26

Figure 3: Level 0 DFD/Context Diagram for the Records Management System ......................... 29

Figure 4: Level 1 Data Flow Diagram .......................................................................................... 30

Figure 5: Entity Relationship Diagram ......................................................................................... 31

Figure 6: Officer Use Case ........................................................................................................... 32

Figure 7: Supervisor Use Case ...................................................................................................... 33

Figure 8: Combined Police Station Use Case Diagram ................................................................ 34

Figure 9: System Architecture ...................................................................................................... 39

Figure 10: High Level Architecture Diagram ............................................................................... 39

Figure 11: Database Schema ......................................................................................................... 41

Figure 12: Login Screen................................................................................................................ 47

Figure 13: Frame Window ............................................................................................................ 48

Figure 14: Form Entry Window .................................................................................................... 49

Figure 15 Register View Window ................................................................................................ 49

Figure 16: Hierarchy Diagram ...................................................................................................... 50

Figure 17: Login ........................................................................................................................... 60

Figure 18: Officer Dashboard ....................................................................................................... 61

Figure 19: OB Register ................................................................................................................. 62

Figure 20: Add OB Details ........................................................................................................... 62

Figure 21: OB Report.................................................................................................................... 63

Figure 22: Search OB.................................................................................................................... 64

7
Figure 23: Check Mail .................................................................................................................. 64

Figure 24: Case Manager .............................................................................................................. 65

8
 LIST OF TABLES

Table 1: Requirements Specification for the Supervisor .............................................................. 35

Table 2: Requirements Specification for the Officer .................................................................... 36

Table 3: User Table ....................................................................................................................... 42

Table 4: Case Files Table .............................................................................................................. 43

Table 5: OB Entries Table ............................................................................................................ 44

Table 6: Unit Testing .................................................................................................................... 54

9
 LIST OF ACRONYMS AND ABBREVIATIONS USED

CIS – Computer Information Systems

DCI – Directorate of Criminal Investigation
ID – National Identification Card and/or any other Identification Document
KPS – Kenya Police Service
OB – Occurrence Book
OCS – Officer in Charge of a Police Station
RMS – Records Management System
XAML – Extensible Application Markup Language

10
CHAPTER 1: INTRODUCTION

1.1 Background

Record keeping is an integral component to any institution. With record keeping comes issues of
integrity, authenticity, accuracy and ease of searching through and updating the data contained
within the records. As the collection of data grows, the need for more sophisticated automatic
processes to find the level of efficiency that is optimal for proper functioning also grows.
A Records Management System is a computer program (or set of programs) used to track and
store records. The term is distinguished from imaging and document management systems that
specialize in paper capture and document management respectively. RMS commonly provide
specialized security and auditing functionalities tailored to the needs of records managers.

The Kenya Police Service, a branch of the National Police Service, is central to the cohesive
operation of our nation. Among its core functions is the responsibility of maintaining law and
order as well as the investigation of crimes and the collection of criminal intelligence to assure
and ensure business continuity and the security of the citizens, a contributor to the nation’s
growth and development. For efficiency in police work, keeping of proper records is essential.
These records are used for the apprehension and charging of criminal suspects in the Kenya
courts of law and for predicting crime, which in turn assists in the prevention of crime.
The Kenya Police Service as of the drafting of this report is still using a manual records keeping
and management system. This is contrary to the Access to Information Act of 2016 (Government
of Kenya, 2016), in which the Police service as a public entity should have not later than three
years from the date from which the Act began to apply, computerized its records and information
management systems in order to facilitate more efficient access to information. This mode of
operation presents a plurality of challenges for both the Police Service as well as for the citizens
of the country. These issues include a lack of transparency in the way the Police Service
operates, dismal efficacy in the execution of its [the Police Service] mandate and poor service
delivery to mention but a few.
This project was undertaken with the aim to address some of the current deficiencies on the
policing side of the Criminal Justice System by giving access to and maintaining a database in
which records of the reports against crime and criminal arrest records will be kept. These records
may include vital records, confidential records, records in poor physical condition, archival
records, official copies, record format types, and records meant for transfer to other media.
One that can be rapidly, easily, conveniently and securely accessed by the key actors in various
police departments. Enhancing efficiency of the Police Service and improving the quality of
services delivered to the citizens.

11
1.2 Problem Definition

Police officers are bombarded with a multitude of information from different sources daily. The
process of tracing records through the Occurrence Book (OB) and locating statements is
cumbersome and difficult. The lack of digitized real-time records is a hindrance to efficient
police functioning.
The method currently used to record and report crime in Kenya is one that involves pen to paper
with the occasional alternative of using spreadsheets to enter critical data.
The files on which records are entered are usually kept in wooden or metal cabinets under lock
and key. Besides this method of storage making the records susceptible to damage by pest and/or
unfavorable environmental conditions, the security of such records is not guaranteed, as most
tend to “disappear” even before the stipulated time set by the law, which is ten years for
occurrence book entries.
Record entry and storage is cumbered with a burgeoning amount of information that has
presented a difficulty to obtain instant information on the nature of prevailing crimes in different
locations in the country. Other issues such as inaccuracy of data entered (spelling mistakes,
wrong time and dates) as well as informational redundancy that leads to conflicts i.e. an singular
incident may be reported at multiple police stations or reported twice on different dates.
It is also very taxing to enquire of the status of a suspect with requests for such critical
information having to be made to the Directorate of Criminal Investigations before a status can
be established with certainty, a process that can take over three days.
These challenges directly affect the veracity of evidence produced in the courts of law, invalidate
the transparency and accountability of the Kenya Police to the public under which the service is
supposed to operate, they hinder optimal and efficient performance by the force and generally
pervert the course of justice.
Existing RMSs that would serve as solutions are unfortunately not ideal for the KPS. Most are
foreign based and apply the workflow processes of the law enforcement agencies of their
countries of origin. The solutions are also very expensive to customize and acquire with most
being split into multiple modules which are sold separately. Alongside the complexity the
systems, the aforementioned challenges would otherwise hinder their successful implementation
and adoption by the KPS.

1.3 Goal

The goal of the project is to digitize records management in a police station by structuring the
data in a way that the officers can grasp and operate under without difficulty.

12
1.3 Project Objectives
1.3.1 Research Objectives

1. To identify, understand and define the current methods of records keeping and
management by the Kenya Police Service.
2. To review related law enforcement management systems in other countries that have
adopted the digitization of law enforcement management of records.
3. To research record management systems extensively and the benefits that
implementing such a system would yield for the Kenya Police Service.

1.3.2 Information System Development Objectives

1. To carry out a feasibility study for the possibility of developing a records

management system for the Kenya Police Service police stations.
2. To design and develop a records management system for the Kenya Police Service
police stations.
3. To test and validate the records management system for the Kenya Police Service
police stations.
4. To implement the records management system for the Kenya Police Service police
stations.

1.4 Project Justification

1.4.1 Service Delivery

If the system is auspiciously implemented and adapted as proposed, then the delivery
of service from the police to the citizens through will be greatly improved. There will
be increased accountability, transparency and integrity. This allocation of cases will
increase accountability for the citizens as they can track the progress of the case and
make complaints to the necessary authorities in case of negligence or laxity.

1.4.2 Automation
The system’s primary purpose is to bring people and processes together by allowing
for the simultaneous access by multiple officers at a time. It is meant to bring
structure to the data collected and make a large conglomeration of information more
manageable, giving the officer only what he/she needs at a time to do his/her job
better. This simply means that information for strategic, tactical, investigative and
administrative uses can be retrieved and linked more effectively and in optimal time.

13
1.4.3 Data Integrity
With the system, the ability to perform repetitive tasks that currently take much
longer by hand will be accorded. An officer will be able to record incidents in the
digital OB which will provide for such mundane things as consistency of spelling and
syntax and the elimination of duplicated effort when entering data.
The system will also allow for the capture of a suspect’s details up to and including
their fingerprints in the cases of criminal offences.
Access to and the retrieval of information will be speeded up and data sharing will be
greatly improved by making the data available conveniently from a central database.
The data stored will be easily updated in the case of errors during entry and the
records kept within the system will be accurate and internally consistent, free of
redundancies.

1.4.4 Decision Making

The system will allow and make it easier for senior police officers to assign cases to
various police officers, sort crime reports by nature and get statistical data to inform
decision making by station heads.

1.4.5 Data Security

The system will also seek to secure the data input and storage. A framework will be
provided for enforcement of data privacy and security policies by allowing special
and specific access to officers with defined roles. For example, an arresting officer
will not be able to expunge the data once entered. Only the Officer in charge of the
police station will be able to effect such a change. The risks of data security breaches
will be greatly minimized.

14
1.5 Project Scope
The system aims to digitize the way data is handled within a police station. It aims to automate
the records management functions of the Kenya Police Service. The system will not include
Computer Aided Dispatch, forensic analysis, decision support or crime scene management
functions.
In the case of crime scenes however, the system will provide for report handling and forwarding.
The project is limited to not reinvent processes, however to enable a better cooperation with
application to enhance processes The system will securely connect to a central database to allow
for quick access to real-time information.

15
CHAPTER 2: LITERATURE REVIEW
2.1 Introduction

Literature review involves the systematic, location and analysis of documents containing
information related to the research problem being investigated. It aims at providing detailed
knowledge of the topic being studied. It helps the researcher uncover what has been done by
other researchers related to the problem being studied. It helps a researcher avoid unnecessary
and unintentional duplication; it also forms the framework within which the research findings are
to be interpreted (Mugenda & Mugenda, 2003).
This chapter explores the particulars of the research undertaken for the project including a review
of the literature detailing the intricacies of the problem domain, and the determinations made. It
begins by addressing how RMS works and what an RMS consists of. Recognizing that a RMS is
not just a means to electronically collect and store reports and information, it holds the core
components, which an officer in charge will rely on to be informed and in order to make sound
and intelligent administrative decisions. It then looks at the institution for whom the system
intends to be developed. The institution’s mandate, work-processes and challenges will be
reviewed. The chapter finally goes on to review existing systems, looking at their pros and cons.
The literature surveyed includes published statistics, the media information available, relevant
information from books, cases, conference papers, journal papers, laws and policies formulated
as well as web-based materials. These materials were supplemented by personal experiences,
physical interviews with civilians in addition to both junior and senior police officers.

2.2 Records Management Systems

For the purposes of this document, the RMS is limited to records directly related to law
enforcement operations. Such records include incident and accident reports, arrest, case
management and other operations oriented records. The RMS does not address the general
business functions of law enforcement agency such as budget, finance, payroll, purchasing and
human resources functions.
A RMS is an agency-wide system that provides for the storage, retrieval, retention,
manipulations, archiving, and viewing of information, records, documents, or files pertaining to
law enforcement operations. RMS covers the entire life span of records development, from initial
generation until the process to which it is relevant is complete. An effective RMS allows single
entry of data while supporting multiple reporting mechanisms. (IACP/COPS, n.d.)
A modern RMS links different data types from multiple users. This allows for the retrieval of
that information for strategic, tactical, investigative and administrative uses. The different data
types include but are not limited to reports, images, photos, master name indexes, evidence and

16
property information, crime mapping, and computer aided dispatch integration. RMS allows the
consumer of the information to look at all available, related and pertinent data on a given
suspect, address, phone number, etc. with the purpose of making sound decisions based on that
integrated information. (LEITSC, 2006)
(Shepherd & Yeo , 2002) Opine that records management policy should be endorsed by senior
management and be made readily available to staff at all levels of the organization. They further
assert that it should sit alongside policy on other matters where best practice is critical to the
achievement of the organization’s goals. If adapted by the KPS a functional RMS can help
prevent, reduce and control crime, improve community policing and problem solving capabilities
as well as improve operational efficiency and resource management. The department and
community benefit from the improved capabilities and efficiencies that RMS has to offer.
Communities are safer because the KPS officers are able to do their jobs better through the
shared capacities of RMS.

2.3 The Kenya Police

The National Police Service derives its mandate from the National Police Service Act, 2011. The
service is made up of three outfits namely; Kenya Police Service, Administration Police Service
and the Semi-Autonomous Directorate of Criminal Investigation. Security is a non-devolved
function and as such, the National Police Service reports to the Inspector-General of Police, and
is a department of Ministry of Interior and Co-ordination of National Government, one of the
two ministries in the Office of the President. The Directorate of Criminal Investigations was
established as a semi-autonomous office of the National Police Service in the Constitution of
Kenya, 2010. The new office was created to ensure a revamped, professional and accountable
service especially on cases of serious nature. Administration Police Service is equipped to tackle
any eventuality regarding law breaking or emergency. It also has an anti-riot unit, an anti-stock
theft unit to deal with livestock theft, a border security unit, and officers to deal with other
violations of the law.
The Kenya Police Service, formerly known as the regular police, conduct day-to-day street
operations and act as the visible face for all Kenyans to see. While organized at a national level,
each arm reports to a County police authority, which in turn divides its force by local Police
Divisions, headquartered at local police stations. A Provincial Police Officer (PPO) heads each
county; each province is further divided into police divisions headed by an Officer Commanding
Police Division (OCPD) normally in the rank of Deputy Commissioner of Police (DCP). The
police divisions are divided into police stations headed by an Officer Commanding Police
Station (OCS). (National Police Service Act, 2011)
As of February 2017, the service fielded about 90,442 officers in its ranks compared to 78,885 in
2013 and 35,000 in 2003. This number represented a ratio of 1 officer for every 489 citizens
(1:489) against the United Nations recommended ratio of 1:450. (Shiundu, 2017)

17
The (National Police Service Strategic Plan, 2013-2018) has recognized slow adoption to ICT
alongside a lack of skills for technology exploitation as being cited as one of the weaknesses of
the National Police Service, acknowledging the fact that leveraging of policing using ICT is an
opportunity and recognizing the rapid change in ICT as a threat.
The National Police Service reports that the total number of crimes reported to the police
increased by 1.3 per cent from 76,986 in 2016 to 77,992 in 2017 while there were 72,490 cases
in 2015 and 69,376 in 2014 (Ombati & Anyango, 2018). This goes to demonstrate that modern
society is characterized by increasing levels of risk posed by internal and external security
threats.
For the Kenya Police Service, adoption of ICTs needs to come sooner rather than later as the
current system of data management has led to low investigating capacities and low access to
police information. The present process used is a manual method whereby when a complaint is
made or an accused person is brought into the police station, the details of such an event are
handwritten into the Occurrence Book (OB). The OB is an A3 size book divided into columns
such as the offence name (topic), the plaintiff/suspect name, ID number, phone number and a
summary of the occurrence/happening report in accordance with (The Penal Code, 2009) and the
(Criminal Procedure Code (Kenya), 2015).
The OB is a legal document that is classified as admissible evidence in courts of law. In the case
of a complaint being made, an OB number is assigned to the case and an extract, which is a small
piece of paper containing the OB reference, as well as the date of the occurrence, is issued to the
complainant. The remark column remains blank for the Officer in Charge of a Police Station
(OCS) to fill.
The plaintiff is then directed to the office dealing with the offence, where another officer records
a detailed report of the offense on the police/accident abstract. With a signature field of on the
report remaining blank for the OCS.
The OCS has the onerous task of leafing through a myriad of records every morning to assign
cases to investigating officers, classifying them according to priority. This is in addition to
his/her [the OCS’s] other responsibilities. In doing this, the OCS assigns an investigating officer
to the case and the investigation begins in earnest.
Once the investigation commences, the collection of evidence begins with the officer recording
the plaintiff’s ensuring it is signed by him/her [the plaintiff], if there were witnesses to the
offense, the plaintiff is instructed to bring them in whereby they too record and sign their
statements. The case is then assigned a status as Pending Arrest of Known Accused (PAKA),
Pending Under Investigation (PY), Pending Before Court (PBC) and Closed.
Once the accused is arrested, the plaintiff is summoned to the station to meet the accused. The
investigating officer writes an entry into the OB, books in the accused and obtains a charge
reference. Upon entry into the cell, the details of the accused, who is at this juncture a suspect in
the offense, are recorded into the cell register. The investigating officer subsequently takes the

18
suspects fingerprints (in the case of a criminal offense) and records their statement. The suspect
is then taken to court before the expiry of 24 hours during working days.
Since the OB is a legal document, at times it is required in court for review and this has led to
most stations having two or more occurrence books with duplicate information in case one is not
present i.e. if it is requested in two or more courts.
The process of entering and searching through OB entries has been observed to be a tedious one,
with most officers complaining of how time consuming the procedure is. Linking the OB to a
series of subsequent documents tied to the complaint or arrest when building a case such as:
police abstracts, p3 (medical examination) forms, accident abstracts, complainant, suspect and
witness statements as well as the arresting officer and the investigating officer’s statements is
cumbersome, prone to errors, consumes a lot of time and frustrating.
This has resulted in many a case ending in mistrials or acquittals as a result of, as the media often
put it, “bungling of investigations”. More often than not however, it is not so much the
investigation that is done incompetently, rather it is usually the misplacement, misdating or
mishandling of evidence files that results in this perversion of the course of justice.

2.3 Current Solutions

2.3.1 CIS Records Management System

The CIS Records Management System (RMS) automates the records management
functions of an agency. The system provides simultaneous on-line use in Records,
Dispatch, Detective Bureaus, etc. RMS is specifically designed for operation by sworn
and clerical personnel. Menus, Tool Bars, Help, and related GUI tools provide an
intuitive and efficient environment for the entire range of personnel that will enter,
access, and track incidents. The system is easy to use according to reviews on Capterra.
(Patricia, 2017)
The CIS RMS however is structured for the American Criminal Justice System and does
not cater for the most essential and most vital parts of the Kenyan Criminal Justice
system such as analysis of the records by officers in charge, the user interface is also not
very good. (Computer Information Systems Inc., 2018)

2.3.2 Polisys
This is a browser-based software solution that includes Computer Aided Dispatch,
Records Management System (RMS), and full mobile computing. The product is easy to
use and requires little training.

19
The solution however, does not provide for case investigation management or a criminal
database, operating primarily as a Computer Aided Dispatch (CAD) system. These
deficiencies fall short of what a Kenyan Police Station would need to have at RMS core.
(Enfosys, 2000)

2.3.3 Coplink
Forensic Logic’s Coplink is a police investigation software that consolidates data from
many sources, aids collaboration and helps generate tactical leads quickly. Used to
generate photo lineups, analyze map data, save search history, and create/export reports
in National Incident Based Reporting Standard (NIBRS) formats to the US FBI, Coplink
is modular police software. There is an entry-level core configuration on cloud designed
for small-medium sized agencies. The full COPLINK suite can be tailored on premise
and on cloud with a variety of optional capabilities.
The system allows my agencies to build complex link analysis charts and interface with
the Records Management System and the Computer Aided Dispatch programs for a
multitude of things. However, average user, use of the system it can be difficult to learn
because the program’s multitude of modules and functionalities. (Forensic Logic, 2017)

2.3.4 CrimeStar
CrimeStar's Records Management System is an easy to use multi-user, network ready
system that automates all of the common record keeping functions of a progressive law
enforcement agency. The system tracks all department activity from the time of the
initial phone call or contact to final disposition and custody of the offenders.
CrimeStar is dispatch oriented which will not suit a Kenya Police Service as they are not
deployed from a central dispatch area, but are interconnected through their police radios.
The senior police act as the dispatch unit and assign officers to respond via the intercom
radios or call them directly on their mobile phones. (CrimeStar Corporation, 1999)

2.3.5 eFORCE Software Suite

eFORCE is a public safety software suite that provides a portfolio of browser-based
solutions including, computer-aided dispatch and records management software and
more.
eFORCE Records Management Software has built-in task management tools that let
police, set up user-specific dashboards. These tools help the police stay on top of their
casework, reports, trainings and certifications and more.
This tool is very comprehensive extends into police duties management. It however, has a
very complex user interface and would require several months of training for the average
officer to get acquainted with its use and perform his/her duties comfortably. It is not

20
 organized to fit perfectly with the established processes in Kenyan Police Stations.
(eForce Software, 2018)

2.3.6 Directorate of Command, Control and Communication (IC3) Centre

The IC3 Centre is an administrative wing of the National Police Service. The centre uses
the Critical Incident Management Suite (CIMS) system that allows them to ‘proactively
and intelligently monitor the public spaces’ (National Police Service, 2018) It contains
within it, a Video Management System, an Automatic Number Plate Recognition
(ANPR) Control System to control all ANPR equipment and archiving/retrieving
recognized license plates as well as a Data Centre.
The systems scope as defined is too wide and does not handle the intricate happenings
within an average KPS station.

2.4 Gap Identified

There currently exists no system developed for the KPS police stations, with most of the systems
identified being too complex, too wide in scope, too expensive to be or being built for other
countries’ jurisdictions to be able to fit into the Kenya Police service police stations. A RMS that
simulates the work process of Kenyan police officers and that adheres to user experience
principles is required in order to cater to the needs of the KPS stations and bring efficiency to the
current records management method as opposed to entirely overhauling it.

21
CHAPTER 3: METHODOLOGY

3.1 System Development Methodology

The system development methodology refers to the framework used to structure, plan and
control the process of developing an information system. The approach proposed will be the
Spiral Model System Development Methodology.

3.1.1 Spiral Development Model

The risk-driven sub setting of the spiral model steps allows the model to accommodate
any appropriate mixture of a specification-oriented, prototype-oriented, simulation-
oriented, automatic transformation-oriented, or other approach to software development.
The spiral model of the software process (Figure 1) was originally proposed by Boehm
(Boehm, 1988). Rather than represent the software process as a sequence of activities
with some backtracking from one activity to another, the process is represented as a
spiral. Each loop in the spiral represents a phase of the software process. Thus, the
innermost loop might be concerned with system feasibility, the next loop with
requirements definition, the next loop with system design and so on. (Sommerville, 2006)
The spiral model combines the iterative nature of prototyping with the controlled
systematic aspects of the waterfall model.
Objective Setting: Specific objectives for that phase of the project are defined.
Constraints on the process and the product are identified and a detailed management plan
is drawn up. Project risks are identified. Alternative strategies, depending on these risks,
may be planned.
Risk Analysis and Reduction: In the risk analysis phase, a process will be undertaken to
identify risks and alternate solutions. A prototype will then be produced at the end of the
risk analysis phase. If any risk is found during the risk analysis, then alternate solutions
are suggested and implemented.
Engineering Phase: In this phase the software/system will be developed, along with
testing at the end of the phase. Hence in this phase the development and testing is done.
Evaluation phase: This phase allows the end-user, who is in this case a police officer to
evaluate the output of the project to date before the project continues to the next spiral.
This way, the software will be developed in a series of evolutionary releases which might
be paper models, or prototypes. Each increment therefore will incorporate prototyping or
complete development of a part.
The first increment will produce a core product, addressing identified core needs. Each
increment will be evaluated either by review or use after which a plan for the next
increment will be drawn up.

22
 This methodology will work in tandem with test driven development so as to guarantee
the proper functioning of the system.

Figure 1: The spiral development methodology (Boehm, 1988)

3.1.2 Justification for the Use of the Model

1. High amount of risk analysis in this project is envisioned hence, avoidance of risk will
be enhanced.
2. Good for large and mission-critical projects – as it will be able to cope with changing
requirements as they can be introduced at any phase of the project.
3. Project monitoring – can be done easily as reviews will be conducted regularly.
4. Software is produced early in the software life cycle and hence system delivery will be
fast.
5. The model will be able to handle time and resources constraints.

23
 3.3. System Analysis
The purpose of the system analysis carried out is to interrogate the working of the current system
with the key question to be considered being, what should be done to solve the problem? The
current system as analysed is mainly manual with close to no digitization. The little digitization
that occurs involves logging entries on Microsoft Access and Excel. There are no dedicated
systems to log and track an OB Entry from its genesis to the closing of a case. Crime statistics
are difficult to obtain, hence creating a challenge when it comes to decision-making and
predicting crime patterns in various areas. There are many redundancies in data entry as well as
duplication of data across registers. The current system is also tedious to search through, messy
to update and easy to lose and often results in neglect of numerous cases and the perversion of
the course of justice.
Crimecle intends to fix these gaps in the existing system by making it easy for officers to log
records, manage their cases and search through existing entries. It also intends to assist officers
in charge in the management of their respective stations. The end goal is to increase efficiency
of service and to boost the officer’s effectiveness on the job.
While connection to a court system is of paramount import especially to cases whose
investigation is complete and need tracking through the criminal justice system, the project as of
now will not include a court module. The system is instead focusing on the workings of the
police station as a first step towards incorporating the entire criminal justice arm of government.
The system analysis undertaken involves feasibility study, requirements specification, object
identification and system modelling.

3.3.1 Feasibility Study

A feasibility study is a test of system proposal according to its workability, impact on the
organization, ability to meet user needs and effective use of resources. An estimate is made of
whether the identified user needs may be satisfied using current software and hardware
technologies. The study considers whether the proposed system will be cost-effective from a
business point of view and whether it can be developed within existing budgetary constraints
(Sommerville, 2006).
The objective of the feasibility study is not to solve the problem, but to acquire a sense of its
scope.
The key considerations are as follows:

3.3.1.1 Technical Feasibility

The technical feasibility carried out determined whether it is possible, in terms of software,
hardware, personnel and expertise, to handle the completion of the project.

24
The system is technically feasible development tools in terms of hardware and software are
available at very low cost to the system builder. The system only requires a singular builder
who possesses the requisite expertise to ensure the successful completion of the project.
The software resources shall be as follows:
 Windows 10 64 Bit Operating System
 Visual Studio Management System 2017
 Microsoft SQL Management Studio 2017
 C# Programming Language
 XAML Markup Language
 ADO.Net Entity Framework
 ImapX Dynamic Linked Library
 Futronic API Dynamic Link Library
Whereas the hardware resource shall be as follows:
 Futronic FS-80 Fingerprint Scanner
 HP Pavilion x360 Laptop

3.3.1.2 Economic Feasibility

The economic analysis to determine the benefits and savings expected from the candidate
system in comparison to the costs revealed that the system is economically feasible. Speed in
record keeping, record retrieval and maintenance translates to shorter times for
interdepartmental coordination, case closure and reduced waiting times by citizens as well as
prosecutors for collation of case files.
All the software and libraries used are available for free, only the fingerprint scanner will be
bought

3.3.1.3 Schedule Feasibility

The time allocated for the undertaking of the project is seven months, which allows for the
completion of the project.
The Gantt Chart below indicates how much time will be allocated to each step of the
development process.

25
Figure 2: Schedule Feasibility Diagram

3.3.1.4 Legal Feasibility

The system is compliant with the set out laws of Kenya as spelt out in the Kenyan
Constitution. Specifically with the National Police Service act of 2011, the Criminal
Procedure Code as well as with the Kenya Access to Information Act of 2016. The systems
operation and flow remains within the confines of Chapter 4, Section 2, Cap 31 on the Right
to Privacy.

3.3.1.5 Operational Feasibility

The system is operationally feasible as intense training will not be required. The user-friendly
interface and a lack of underlying complex operations will make it easy for novice and first-
time computer users to get a handle on the operation of the system. The system’s structure
will integrate into the police deskwork process easily.

3.3.1 Requirements Elicitation

Researching and discovering the requirements of the system from users and other stakeholders
made use of practices such as interviews, user observation and document analysis.
a. Interviews
One on one interviews was the integral method used to gain information and user
requirements of the system.
26
 The aim of the interviews was to understand the officers’ and station supervisor’s
perspectives on police work, how it is conducted as well as how to make the work processes
more efficient. The interviews were conducted on premises applying the empathy mode of
interviewing. This technique produced satisfactory results.
b. Observation/Social Analysis
This technique was used to gather requirements by observing the way the existing system of
logging entries takes place. Question on the difficulty of the process as well as what
measures could be taken to improve it were asked, making note of the user’s experience and
of areas that can be improved and digitized.
c. Document Analysis
Information was gathered from various documents especially those relating to the law. An
analysis of The National Police Service act, the Penal Code and the Criminal Procedure code
was essential to gaining information on police processes, the documents used and the charges
proffered against various offences. Documents relating to Law Enforcement Management
Systems how they work and how they are implemented, helped in gathering ideas on how to
implement the candidate crime records management system.

Key Findings
1. Cases are built from the OB entry; it constitutes the initial incidence report.
2. The OB entries are made to a book called the OB Register, which is usually produced as part
of evidence in court.
3. The OB entry feeds what is known as the Charge Register which informs cases as well as the
Cell Register which comprises of the names of persons who have been remanded in police
custody before release or production before a magistrate in a court of law.
4. The OCS makes remarks on the OB Register and has the responsibility of assigning cases.
5. Felonies committed require the capturing of fingerprints to be forwarded to the Directorate of
Criminal Investigations and acquire a Criminal Registration Office (CRO) number, which is
a criminal offence number for the offender. Misdemeanours or infractions do not require the
capturing of fingerprints and do not result in the creation of a lifetime criminal offence
number for person charged.
6. The Charges placed on the Charge Register are based on the Kenyan Penal Code.
7. OB search, which is the process of determining whether an OB entry that is claimed to have
been made is existent, is carried out with a lot of frequency especially when cases are being
built or when a complainant is following up on a reported incident. The process of searching
for OB records is long and arduous.

27
3.3.2 Proposed System
The system will consist of multiple modules within each user role, a police station simulation
that will take on the form of an installable desktop application connecting to a central
database. The application will consist of users assigned the following roles:
 A supervisor – Performs administrative tasks such as adding users, viewing records,
editing and expunging records, assigning cases, making remarks, reassigning user
roles on the system.
 An officer – Performs regular police tasks such as creating and updating occurrence
book entries, building cases assigned and adding other necessary records such as
arrests and overnight reports.
The best practice recommended is that the supervisor role be restricted to only the O.C.S and
his/her deputy. The supervisor will add a user and assign them an officer’s role.
The officer will be able to log OB entries and update them. These OB entries will link to
complaints, station reports, accident reports and arrest reports. The supervisor who will assign
cases to officers and make remarks will view the entries. Once a case is assigned, an officer
can use the case management module to build his/her case by linking the charge sheet, their
reports, witness statements, complainant statements and statements of the accused to those
existing OB entries. These cases will be stored in such a way that they are easily retrievable
and accessible to the investigating officer for subsequent forwarding to the Office of Public
Prosecutions.
In the case of an arrest, the officer will be able to take the accused details, alongside the
charge and store them. A cell manager module will reference the details in the case of an
accused person who is required to remain in custody.
The officer will be able to search through records and obtain the information required easily.
The supervisor will view OB Entries logged by date, make remarks and assign cases to
officers. He/she will also be able to search through records and filter by date location, date and
officer who logged the entry.
The supervisor will obtain statistics by area, nature of crime and by month. He/she will also
be able to audit the officer logs by viewing reports generated from officer interactions with the
system.

28
 3.3.3 Data Modelling

Data modeling is a process used to define and analyze data requirements needed to support the
business processes within the scope of corresponding information systems in organizations.
Therefore, the process of data modeling involves professional data modelers working closely
with business stakeholders, as well as potential users of the information system

3.3.3.1 System Context Diagram/ Level 0 Dataflow Diagram

System Context Diagrams represent all external entities that may interact with a system. Such
a diagram pictures the system at the center, with no details of its interior structure,
surrounded by all its interacting systems, environments and activities. The objective of the
system context diagram is to focus attention on external factors and events that should be
considered in developing a complete set of systems requirements and constraints (Kossiakoff
& Sweet, 2011).

Figure 3: Level 0 DFD/Context Diagram for the Records Management System

3.3.3.2 Level 1 Data Flow Diagram

A data flow diagram (DFD) is a graphical representation of the "flow" of data through an
information system, modelling its process aspects. A level 1 data flow diagram provides a
more detailed view of the Context Level Diagram detailing system functions. These
functions include:
1) User Creation
2) Create OB Records
3) Assign Cases to Officer
4) Create Case Records
5) Generate Reports

29
 6) Generate Statistics

Figure 4: Level 1 Data Flow Diagram

30
3.3.1.1 Entity Relationship Diagram
An entity-relationship (ER) diagram also called an entity relationship model, is a graphical
representation of entities and their relationships to each other, typically used in computing in
regard to the organization of data within databases or information systems. An entity is a
piece of data-an object or concept about which data is stored (Beal, 2018).

Figure 5: Entity Relationship Diagram

31
 3.3.3.3 UML Use Case Diagrams

These diagrams are behavior diagrams used to describe a set of actions (use cases) that some
system or systems (subject) should or can perform in collaboration with one or more external
users of the system (actors). Each use case should provide some observable and valuable
result to the actors or other stakeholders of the system.

Figure 6: Officer Use Case

32
Figure 7: Supervisor Use Case

33
Figure 8: Combined Police Station Use Case Diagram

Shows how the police station supervisor and officer interact with the system, upon login
to his module, the supervisor is able to add new users, edit existing users by changing
their roles, status etcetera. The supervisor will be able to search, view and edit OB entries
by assigning cases to officers, making remarks on the same and updating an OB entry, an
action that will reflect on the officer’s module. The supervisor will also be able to
expunge a record entry and generate statistics as well as reports.
The officer on the other hand will be able to add OB entries, classify them as arrests,
complaints, accidents or station status reports. He/she will also be able to search, view
and edit OB record entries as well as build cases from the self-same OB entries in the
case where he/she is assigned to a case.

34
3.3.1. Requirements Specification

Requirements specification is the activity of translating the information gathered during the
analysis activity into a document that defines a set of requirements (Sommerville, 2006).
This section provides a high-level specification of the system as well as identify the users
involved and explain their roles. It contains two parts, namely the user requirement and
system requirement.
3.3.1.1. User Requirements
User requirements specification specifies what the user expects the software to be able to
do. The tables below contain within them descriptions of the requirement as well as their
importance to the user’s work process.
Table 1: Requirements Specification for the Supervisor

Requirement Description Importance

Be able to add and edit users The supervisor should be able High
to login to his/her dashboard
and add or edit users to grant
them access to the system.

Be able to edit, add remarks The supervisor should be able High

and assign cases to OB to edit, expunge and make
entries remarks on the OB entries as
well as assign particular
officers to cases as the case-
investigating officer.

Be able to view user reports The supervisor should be able Low

to view user reports such as
login reports, OB edit reports
and OB entry reports
Send mail to officers The supervisor should be able High
to send mail to individual
officer and post messages
onto the officer’s message
board.

35
Table 2: Requirements Specification for the Officer

Requirement Description Importance

Be able to add and edit OB The officer should be able to High

entry log a new OB entry, record it
as an accident, complaint, and
arrest or station status report
and update it when
authorized.

Be able to build a case from The officer should be able to High

OB Entry build a case file from an OB
Entry once he/she is assigned
as the investigating officer.
Should be able to link
statements and reports to the
OB Entry in order to build a
case.

Be able to add details to the The officer should be able to High

cell register. link arrest records to cell
register in the case of accused
persons held in custody.

3.3.1.2. System Requirements

The system requirements are set in order to ensure that the system creation fits into the
scope as optimally as possible. These requirements are classified into two groups, the
functional and no-functional requirements.
3.3.1.2.1. Functional Requirements
These requirements describe the features or functionalities that are required by the
system.
For the supervisor role:
 The system should allow the supervisor to add and edit users
 The system should allow the supervisor to view, edit and update OB Entries.
 The system should allow the supervisor to search records by date, and arrest
as well as cell records by name and/or identity numbers.

For the officer role:

36
  The system should allow the officer to add update and view OB entries.
 The system should allow the officer to search records by date, and arrest as well as cell
records by name and/or identity numbers.
 The system should allow the officer to link arrest records to the cell register.
 The system should allow the officer to build a case from an OB entry and link case files
to investigating officer reports and statements.

3.3.1.2.2. Non-functional Requirements

The specific criteria that can be used to judge the operation of the system is includes
the following:
Usability
The system should be easy for the police officer to learn how to use and work with by
simulating and simplifying the complexities of their work process and assisting them
reach their quantified objectives with effectiveness, efficiency, and satisfaction.
Effectiveness
The system should respond quickly to user inputs and produce expected outputs.
Compliance
The system should comply with relevant laws, policies, and regulations to enable
police departments meet their goals.
Data Integrity
The system should provide the maintenance, assurance of the accuracy and
consistency of, data input over its entire life cycle.
Security
The system should guard against unauthorized and unauthenticated access to ensure
the protection of classified and sensitive information added within it.
Extensibility
The system implementation shall consider future growth and incorporate the ability to
be update easily and extension or adding of functions typically, enhancements – while
minimizing impact to existing system functions.

37
 3.4. System Design

A software design is a description of the structure of the software to be implemented, the data
which is of the system, the interfaces between system components and, sometimes, the
algorithms used. The systems design process partitions the requirements to either hardware or
software systems. It establishes an overall system architecture. Software design involves
identifying and describing the fundamental software system abstractions and their relationships
(Sommerville, 2006).
The design process translates requirements into a representation of the software that can be
assessed for quality before coding begins. During design, different modules were designed as
represented by the:

3.4.1. Architecture Design

3.4.1.1. System Architecture

A system architecture or systems architecture is the conceptual model that defines the
structure, behavior, and more views of a system (Jaakkola & Thalheim, 2011).
A system architecture can consist of system components and the systems developed, that
will work together to implement the overall system (Clements, 1996).
The system is designed in the following manner. The Records Management system has a
backend engine that consists of a Microsoft SQL database, ADO.Net as the link to the
database and C# as the programming language of the user interface modules. The system
architecture is illustrated in the figure below.

38
 Figure 9: System Architecture

3.4.1.2. High Level Architecture Diagram of The Main Components

Records Management System

OB Records Case Records Reports Statistics

Manageme Management

Figure 10: High Level Architecture Diagram

39
3.4.2. Database Design

3.4.2.1. Logical Design

Logical database design is the process of transforming (or mapping) a conceptual schema
of the application domain into a schema for the data model underlying a particular
DBMS, such as the relational or object-oriented data model (Borgida, et al., 2009).
The logical database design describes the representation of the database in terms of its
entities in form of tables and the existing relationships. The figure below presents an
illustration of the logical design of the system.

40
Figure 11: Database Schema

41
3.4.2.2 Physical Design
As one of the core elements of a records management system, the database had to be
designed in an exacting and systematic manner. This process started at the analysis
phase of the project. From the analysis, the researcher was able to identify the
necessary tables required for the database and the associated field names, format and
length of each table. After careful analysis of the user requirements, it was identified
that the RMS needed three main tables i.e. ob entries, case files, and the users table.

3.4.2.2.1 Database Tables

Table 3: User Table

Attribute Data Type Length/Size Description

UserID int 11 Unique user identifier
FirstName nvarchar 50 User’s first name
LastName nvarchar 50 User’s last name
BadgeNumber int 11 User’s service
number
OfficerGender nvarchar 100 User’s sex
OfficerStatus nvarchar 100 User’s work status
Role nvarchar 50 User’s role on the
system
Rank nvarchar 100 User’s official rank
Password nvarchar 250 User’s encrypted
password
PhoneNumber nvarchar 20 User’s mobile
number
EmailAddress nvarchar 100 User’s contact email
address
OfficerImage varbinary 8000 User’s official
identification image
RightThumbPrint varbinary 8000 User’s right thumb
print
RightForeFinger varbinary 8000 User’s right
forefinger print
RightMiddleFinger varbinary 8000 User’s right middle
finger print
RightRingFinger varbinary 8000 User’s right ring
finger print
RightLittleFinger varbinary 8000 User’s right little
finger print

42
 LeftThumbPrint varbinary 8000 User’s left thumb
print
LeftForeFinger varbinary 8000 User’s left forefinger
print
LeftMiddleFinger varbinary 8000 User’s left middle
finger print
LeftRingFinger varbinary 8000 User’s left ring finger
print
LeftLittleFinger varbinary 8000 User’s left little
finger print

Table 4: Case Files Table

Attribute Data Type Length/Size Description

CaseID int 11 The case’s unique
identifier
UserID int 11 The user
adding/editing the
case
CaseFileNumber nvarchar 20 The case file number
for the charge
register
ObNumber nvarchar 20 The OB that is the
case’s origin
ReportDetails text The OB report details
ComplainantStatement text Recorded
complainant
statement
WitnessStatement text Recorded witness
statement
AccusedStatement text Recorded accused
statement
OfficerStatement text Officer case report
RelatedFiles varbinary 8000 Related case files i.e
P3 forms, images
CaseStatus nvarchar 100 Status of the case
whether pending or
closed

43
Table 5: OB Entries Table

Attribute Data Type Length/Size Description

ObID int 11 Unique OB
identifier
UserID int 11 Identifier of user
making OB entry
ObType nvarchar 50 Type of OB entry
whether complaint,
arrest etc.
ObRem nvarchar 50 Date of OB being
taken
ObNumber nvarchar 50 OB Number
ReportDate date Date Occurrence
reported
ObRefNumber nvarchar 50 OB that refers to the
current incident
being reported
SubjectName nvarchar 100 Name of person
making report
SubjectAddress nvarchar 100 Address of person
making report
OccurenceLocation nvarchar 100 Location at which
the incident
occurred
OccurenceDate nvarchar 100 Date on which the
incident occurred
OccurenceNature nvarchar 100 Nature of the
incident that
occurred
CrimeType nvarchar 100 Type of crime
committed in
relation to the
incident
ReportDetails text Details of the
occurrence
RecordedBy nvarchar 100 Name of officer
recording the
incident
ReportedAt nvarchar 100 Station at which the
incident was
reported
LastEditDate datetimeoffset 7 Last time the OB
entry was updated
OfficerAssigned nvarchar 100 Officer assigned to
the case

44
OcsRemarks text Remarks from the
supervisor
CulpritName nvarchar 100 Name of person
arrested
CulpritAlias nvarchar 100 Alias of person
arrested
CulpritIDNumber nvarchar 100 ID number of person
arrested
CulpritType nvarchar 100 Type of person
arrested
CulpritTribe nvarchar 100 Tribe of person
arrested
CulpritGender nvarchar 100 Gender of person
arrested
CulpritResidence nvarchar 100 Usual place of
residence of person
arrested
CulpritDOB nvarchar 100 Date of birth of
person arrested
OffencesCharged nvarchar 100 Charges pressed
against person
arrested
ArrestingOfficerBadge int 11 Badge number of
officer effecting the
arrest
ArrestingOfficerName nvarchar 100 Name of officer
effecting the arrest
CulpritMugshotF varbinary 8000 Front facing
mugshot of arrested
person
CulpritMugshotR varbinary 8000 Right side facing
mugshot of arrested
person
CulpritMugshotL varbinary 8000 Left side facing
mugshot of arrested
person
RightThumbPrint varbinary 8000 Culprit’s right
thumb print
RightForeFinger varbinary 8000 Culprit’s right
forefinger print
RightMiddleFinger varbinary 8000 Culprit’s right
middle finger print
RightRingFinger varbinary 8000 Culprit’s right ring
finger print
RightLittleFinger varbinary 8000 Culprit’s right little
finger print

45
 LeftThumbPrint varbinary 8000 Culprit’s left thumb
print
LeftForeFinger varbinary 8000 Culprit’s left
forefinger print
LeftMiddleFinger varbinary 8000 Culprit’s left middle
finger print
LeftRingFinger varbinary 8000 Culprit’s left ring
finger print
LeftLittleFinger varbinary 8000 Culprit’s left little
finger print
FingerPrintTaker nvarchar 100 Name of officer
taking culprit finger
prints
FpTakerRank nvarchar 100 Official rank of
officer taking culprit
finger prints
DateFPTaken date Date fingerprints
were taken
ArrestMethod nvarchar 100 Method of arrest of
culprit
Custody int 1 Whether or not
culprit is being
placed in custody
CulpritSerialNumber nvarchar 100 Serial number
assigned to culprit in
custody
CulpritPhysicalCondition text Physical condition
of culprit in custody
AdmittedBy nvarchar 100 Name of officer who
admitted the culprit
into custody

Based on the tables displayed above, the main/core tables are linked together by
one Unique key which is UserID.

46
3.4.3 User Interface Design

User interface design is the is the design of user interfaces for software with the goal of
making the user's interaction as simple and efficient as possible, in terms of
accomplishing user goals (user-centered design).

3.4.3.1 Wireframes
The wireframes below represent the skeletal framework of the system’s user interface

Figure 12: Login Screen

47
Figure 13: Frame Window

48
Figure 14: Form Entry Window

Figure 15 Register View Window

49
3.4.3.2 Hierarchical Input Process and Output
The figure below illustrates the flow of events in the RMS.

Figure 16: Hierarchy Diagram

50
CHAPTER 4: SYSTEM IMPLEMENTATION
4.1 Overview

The implementation stage of software development is the process of converting a system

specification into an executable system. Steps involved during this process include conversion of
physical design specification gathered to actual code and testing the code for bugs. The system
was implemented as a desktop application as opposed to it being a web application due to factors
such as:

1. Desktop applications usually have more control over a user’s computer compared to a web
application.
2. Desktop applications are often offline and do not need an Internet connection to function
compared to a web application.
3. There are many security concerns regarding web applications. Desktop applications have
a lower chance of having security issues.
4. Native desktop applications performs far better in terms of memory and speed.
5. Desktop applications provide better stability and are more extensible compared to web
applications.

4.2 Software Requirements

1. Visual Studio Community Edition 2017

2. C# Programming Language
3. Extensible Application Mark-Up Language (XAML)
4. Microsoft SQL Server Management Studio 2017
5. Windows 10 Home Edition (64 Bit)

51
Software Justification
1. C#
C# (pronounced ‘C sharp’) is a is a general-purpose, multi-paradigm programming
language encompassing strong typing, imperative, declarative, functional, generic,
object-oriented (class-based), and component-oriented programming disciplines. The
language is designed for developing apps on the Microsoft platform and requires the
.NET framework on Windows to work. C# is often thought of as a hybrid that takes
the best of C and C++ to create a truly modernized language. C# is stable, does not
require .h header files and has many useful libraries that assist in the development of
software.

2. XAML
XAML is a declarative XML-based language developed by Microsoft that is used for
initializing structured values and objects. XAML forms a user interface markup
language to define UI elements, data binding, events, and other features. It has high
graphical capabilities and uses a combination of it alongside C# as a programming
layer results in the Windows Presentation Foundation or WPF, which is a set of tools
classes and libraries for creating windows applications.
3. Microsoft SQL Server Management Studio 2017
SQL Server is a relational database platform that a .NET application can easily
integrate and connect to without writing complex code. It can store procedures
connect to the visual studio IDE and can be set up on entity framework classes in
.NET to use LINQ queries. LINQ queries simplify database querying. The choice to
use Microsoft SQL was informed by the intent to migrate the database to the Azure
cloud in order to have a distributed homogenous database for all police stations
country wide.
4. Entity Framework
Entity Framework (EF) is an open-source, object-relational mapping (ORM)
framework for ADO.NET. The framework was chosen as it is proven to assist .NET
developers to work with a database using .NET objects. It eliminates the need for
most of the data-access code that developers usually need to write.

52
 4.3 Hardware requirements
The system works best if the following computer requirements are met

1. At least 1 GB of RAM.
2. 40 GB hard disk storage
3. 1.5 GHz Pentium Processor
The RMS should run on a machine that has connectivity to Microsoft Azure or has SQL
server installed on it. Such a machine should have relatively high processing speeds
(approximately 1.4 GHz processor) so as not to slow exchange of information with the
server and to enable it to carry out core functions such as search and addition of records
without prolonged wait times.

4.4 System Testing

The purpose of this stage is to ensure system satisfy user requirements using test data.
Input and output processes of the system is laid down in terms of how data is input into
the system, how it is verified or authenticated, how it is processed, and how it is
displayed as output or stored.

The main inputs to the system are user’s details which are captured by use of WPF
forms. These details which are submitted to the database are used in the authentication
of specific users of the system and in the granting of access according to assigned roles.
User details are also captured by the system. Test cases for various submissions are
shown below

Unit tests detect changes that may break the design contract, thus helping in changing
and maintenance of the code.
Unit test was designed to test functional units upon completion. Individual testing of
functional units was carried out for validation purposes as well as to inform the code
refactoring and library upgrades. The table below details a sample of unit tests carried
out

53
Table 6: Unit Testing

Functional Unit Description Input Expected Results Actual Output

Login User validation Correct username User should be User is granted

and verification and password granted access access and a new
and a new window opens
window opens based on the user
based on the user role
role
Wrong username User should be User should be
and password denied access and denied access and
an error message an error message
displayed is displayed
Add New Record Creation of a new Fill in OB/ Case New record New records is
OB or Case File details and report should be created created and a new
record and a new report report window
window opens opens with a
with a success success message
message
Missing New record New record is no
mandatory details should not created created and an
or report and an error error message
message indicating missin
indicating missing detail values is
detail values is displayed
displayed
Add User Creation of a new Fill in user details New user should New user is
user and capture be created and a created and a new
fingerprints new report report window
window opens opens with a
with a success success message
message
Missing New user should New user is not
mandatory user not be created and created and an
details or an error message error message
fingerprints indicating missing indicating missin
values is values is
displayed displayed

54
CHAPTER 5: CONCLUSION
5.1 Summary of Achievements
The following achievements were realized in terms of functionality development:
1. Access control for the system users based on their roles.
2. The linking of OB records to other records when building a case
3. The integration of fingerprint capture for users as well as persons suspected of
committing felonies.
4. Allowing for easy searching and updating of record entries.
5. The centralization of OB, charge and cell registers.

5.2 Constraints

The following functionalities were partially implemented as originally planned due to

reasons explained:
1. Implementation of the fingerprint login : due to the quality of the fingerprint scanner,
security of the system would have been compromised.
2. Implementation of crime statistics : due to the complex statistical analysis that is
required in order to generate statistics in various areas of jurisdiction.
3. Implementation of usage reports: due to the incompatibility of WPF with RDLC
reports
The scope of the project was limited to the policing side of the criminal justice system and
did not include certain key areas of interest such as computer aided investigations.

5.3 Conclusion
No insurmountable challenges were met, the researcher was able to complete the system,
fulfill the objectives and gain a lot of experience from the process. The researcher became
better versed in user centered design and development and was able to apply design thinking
techniques in order to acquire information needed for the project.
If the Kenya Police Service successfully adopts the system, with the recommendations above
added to foolproof it, the efficiency of service from the Kenya Police to the citizens is
projected to improve without bounds putting the service well on the way towards achieving
set out reforms.

55
5.4 Recommendations for Further Work
The following recommendations to the system can be implemented in order to extend the
system and allow it better efficiency.
 An in depth analysis into the statistical methods used to obtain criminal statistics will
be delved into so as to inform the statistics function of the RMS.
 A proper reporting mechanism compatible with the system will be adopted to
improve the system’s current reporting.
 Expansion of the system to assist in station personnel management, inform
performance appraisals and increase accountability of junior officers to their seniors.
 Implementation of the fingerprint login upon acquisition of a better fingerprint
scanner.
 The inclusion of AI techniques in the analysis and generation of statistics by use of
heat maps to assist decision making.
 Use of a cloud based database with advanced security in order to allow the entire
Kenya Police Service to have access to a singular database.
 The system could also be expanded to allow for computer aided dispatch and to link
to a court management system and a jail management system.

56
REFERENCES
Baje, E. N., 1998. Records Management Programme in Oyo State Civil Service, a study of
Governor’s office, Ibadan: s.n.
Beal, V., 2018. Entity Relationship Diagram (model). [Online]
Available at: https://www.webopedia.com/TERM/E/entity_relationship_diagram.html
[Accessed 11 10 2018].
Boehm, B., 1988. A spiral model of software development and enhancement. IEEE, 21(5), pp.
61-72.
Borgida, A., Casanova, M. A. & Laender, A. L., 2009. Logical Database Design: from
Conceptual to Logical Schema, Boston: Encyclopedia of Database Systems.
Clements, P. C., 1996. A survey of architecture description languages. Proceedings of the 8th
international workshop on software specification and design.
Computer Information Systems Inc., 2018. Systems and Solutions. [Online]
Available at: https://www.cis.com/systems/#1512163022215-441d416d-a796
[Accessed 22 May 2018].
CrimeStar Corporation, 1999. CrimeStar RMS Information and FREE Evaluation Copy. [Online]
Available at: https://www.crimestar.com/info.html
[Accessed 23 May 2018].
Criminal Procedure Code (Kenya), 2015. Criminal Procedure Code, Kenya[Act No. 27], s.l.:
National Council for Law Reporting.
eForce Software, 2018. Records Management. [Online]
Available at: https://www.eforcesoftware.com/product/records-management-system
[Accessed 23 May 2018].
Enfosys, 2000. PoliSys® Enterprise Edition. [Online]
Available at: http://enforsys.com/products/polisys-enterprise-edition/
[Accessed 10 October 2018].
Forensic Logic, 2017. Forensic Logic Announces Acquisition of COPLINK Platform from IBM.
[Online]
Available at: https://forensiclogic.com/forensic-logic-announces-acquisition-of-coplink-
platform-from-ibm/
[Accessed 10 October 2018].
Government of Kenya, 2016. Access To Information Act, s.l.: National Council for Law
Reporting.

57
IACP/COPS, n.d. Records Management Systems, s.l.: International Association of Chiefs of
Police/Department of Justices’ Community Oriented Policing Services Technology Technical
Assistance Program’s.
Jaakkola, H. & Thalheim, B., 2011. Architecture-driven modelling methodologies. Proceedings
of the 2011 conference on Information Modelling and Knowledge Bases, Volume XXII, p. 98.
Kossiakoff, A. & Sweet, W. N., 2011. Systems Engineering: Principles and Practices. In:
Systems Engineering: Principles and Practices. s.l.:s.n., p. 266.
LEITSC, 2006. Functional Standards Guide, s.l.: Law Enforcement Information Technology
Standards Council.
Mugenda, O. M. & Mugenda, A. G., 2003. Research Methods: Quantitative and Qualitative.
African Centre for Technology Studies ed. Nairobi: s.n.
National Police Service Act, 2011. National Police Service Act, s.l.: Government of Kenya.
National Police Service Strategic Plan, 2013-2018. National Police Service Strategic Plan,
Nairobi: Office of The Inspector General.
National Police Service, 2018. Directorate of Command, Control and Communication (IC3)
Centre. [Online]
Available at: http://www.nationalpolice.go.ke/2015-09-22-11-51-11/director-command-control-
and-communication-ic3-centre.html
[Accessed 10 October 2018].
Odit, D., 2011. A Case Study of the Maternal and Child Health Section, Mbarara: Mbarara
University of Science and Technology..
Ombati, C. & Anyango, J., 2018. Police releases latest crime statistics in Kenya. [Online]
Available at: https://www.standardmedia.co.ke/article/2001278742/police-releases-latest-crime-
statistics-in-kenya
[Accessed 10 October 2018].
Patricia, M., 2017. CIS Records Management System Reviews. [Online]
Available at: https://www.capterra.com/p/102675/CIS-Records-Management-System/#reviews
[Accessed 23 May 2018].
Shepherd , . E. & Yeo , G., 2002. Managing Records: A Handbook of Principles and Practice
(The Facet Records Management Collection). London: Facet Publishing.
Shiundu, A., 2017. Is there 1 police officer serving every 390 Kenyans, as Kenyatta said?.
[Online]
Available at: https://africacheck.org/reports/is-there-1-police-officer-serving-every-390-kenyans-
as-kenyatta-said/
[Accessed 24 May 2018].

58
Sommerville, I., 2006. Software Engineering. In: Software Engineering. St Andrews: Addison-
Wesley, pp. 67-77.
The Penal Code, 2009. The Penal Code(Kenya) - Chapter 63 of the Constitution, s.l.: National
Council for Law Reporting.

59
APPENDICES

APPENDIX A: USER AND TECHNICAL MANUAL

Getting Started
System Requirements

 Operating System: Windows Vista, 7, 8, or Higher

 Computer Processor: Intel Pentium 4, Pentium M, Core or Atom, AMD Athlon 64 or
later.
 Computer Memory:1GB or more
 Screen Resolution:1024x768 pixels or higher

Logging In

To logon and start using your Crimecle RMS, type in your badge number and password code to
access the RMS.

Figure 17: Login

60
Crimecle RMS Using the System
Once you’ve been logged in successfully, click on any shortcut on the dashboard or the side panel to get
access to that window

Figure 18: Officer Dashboard

61
To add a new OB entry, click on Ob Register and Click Add -- Record on the subsequent window. This is
up to the user’s discretion.

Figure 19: OB Register

Add OB Details and Confirm the Save

Figure 20: Add OB Details

62
Once Saved, the OB Manager window will open, from here you can search or update OB Entries

Figure 21: OB Report

Example search:

63
Figure 22: Search OB

The same process applies for arrest and other types of OB Entries
To view cases assigned and specific information from superior, click on mail and login using
your credentials.

Figure 23: Check Mail

64
If a case has been assigned to you, click on ‘Case Manager’ to access the investigation
management module. Click on build case and select an OB entry to begin working on the case

Figure 24: Case Manager

65
APPENDIX B: SAMPLE CODE

Code to login User

using System;
using System.Collections.Generic;
using System.Data;
using System.Data.SqlClient;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Data;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Imaging;
using System.Windows.Shapes;

namespace crimecle
{
/// <summary>
/// Interaction logic for LoginPage.xaml
/// </summary>
public partial class LoginPage : Window
{
public LoginPage()
{
InitializeComponent();
}

private void btnAccess_Click(object sender, RoutedEventArgs e)

{
SqlConnection sqlCon = new SqlConnection(@"Data Source=.; Initial Catalog=CrimecleDB; Integrated
Security=True;");

try
{
if (sqlCon.State == ConnectionState.Closed)
sqlCon.Open();
String query = "SELECT COUNT(1) FROM dbo.users WHERE badgeNumber=@Username and
passWord=@Password";
SqlCommand sqlCmd = new SqlCommand(query, sqlCon);
sqlCmd.CommandType = CommandType.Text;
sqlCmd.Parameters.AddWithValue("@Username", txtUsername.Text);
sqlCmd.Parameters.AddWithValue("@Password", txtPassword.Password);
int count = Convert.ToInt32(sqlCmd.ExecuteScalar());
if (count == 1)
{
SqlDataAdapter sda = new SqlDataAdapter("SELECT role FROM users WHERE badgeNumber='" +
txtUsername.Text + "' and passWord='" + txtPassword.Password + "' ", sqlCon);
DataSet ds = new DataSet();
sda.Fill(ds, "Login");
String role = ds.Tables[0].Rows[0]["role"].ToString();
if (role == "Supervisor")
{

66
 SupervisorDashboard dashboard = new SupervisorDashboard();
dashboard.Show();
this.Close();
}

else
{
OfficerDashboard dashboard = new OfficerDashboard();
dashboard.Show();
this.Close();
}

}
else
{
MessageBox.Show("Username or Password is Invalid");
txtUsername.Text = "";
txtPassword.Password = "";
txtUsername.Focus();
}

catch (Exception ex)

{
string message = "Username or Password Cannot Be Blank " + ex.Message;
string caption = "Invalid Action";
MessageBoxButton buttons = MessageBoxButton.OK;
MessageBoxImage icon = MessageBoxImage.Error;
MessageBox.Show(message, caption, buttons, icon);
}

finally
{
sqlCon.Close();
}
}

private void Window_Loaded(object sender, RoutedEventArgs e)

{
txtUsername.Focus();
; }
}
}

67
 APPENDIX C: SAMPLE INTERVIEW QUESTIONS
1. What does constitutes a day in the life of a police officer?
2. What is the hardest part about your job?
3. What do you enjoy most about your work?
4. Describe the procedure of logging an OB entry in depth.
5. Describe the criminal procedure code in depth.
6. What are the functions of various police seniors?
7. How are crimes charged?
8. Explain the process of building a case, as well as its challenges.
9. How do the KPS coordinate with other National Police Service branches?
10. Has your job affected or interfered with your personal life?
11. Do you ever feel misunderstood by civilians?
12. Are there things you wish would be done to ease your workflow?
13. What are your thoughts on information technology i.e. digitization of your work?
14. What are your recommendations for the digitization process?

68

View publication stats