Executive summary

Law enforcement agencies face significant challenges due to outdated and inefficient crime record-
keeping systems. The reliance on paper-based or legacy software solutions results in numerous
issues, including time-consuming manual processes, increased error rates, and limited information
accessibility. These limitations hinder collaboration between departments and jurisdictions,
compromise data security, and impede the efficiency of case investigations.
The consequences of these challenges extend beyond operational inefficiencies, impacting resource
allocation, transparency, and public trust in law enforcement. Delays in accessing critical
information hinder investigations and reduce case-solving rates. Additionally, the lack of robust data
analysis capabilities makes it difficult to identify crime trends and allocate resources effectively.
To address these issues, there is a pressing need for modernized crime record-keeping systems that
prioritize efficiency, accessibility, and data security. By implementing advanced technologies and
fostering interagency collaboration, law enforcement can enhance operational effectiveness,
streamline workflows, and improve public confidence in their ability to combat crime.

1. Selecting a Software Project

a. Area of Interest: Law Enforcement and Criminal Justice
b. Possible Software Systems:
Crime Mapping Software
Evidence Management Systems
Jail Management Systems
Crime Record Management System (CRMS)
c. Chosen System: Crime Record Management System (CRMS)
The police is still struggling with outdated and inefficient crime record-keeping systems. These
paper-based or legacy software solutions lead to a multitude of problems. Manually accessing and
updating records is time-consuming, increasing the risk of errors and inconsistencies. Limited
accessibility restricts information sharing between departments and jurisdictions, hindering
collaboration. Furthermore, physical records are vulnerable to loss, theft, or damage, posing
security risks [1]. These limitations have a ripple effect, impacting case investigation efficiency,
resource allocation, and overall transparency. Delays in accessing information can stall
investigations and reduce case-solving rates. Without robust data analysis capabilities, identifying
crime trends and allocating resources strategically becomes difficult. Limited information sharing
across agencies impedes collaboration and coordination, and inaccurate or inaccessible data
undermines public trust in law enforcement [2].
2. Work breakdown structure
Actual Actual
Estimated Estimated Estimated Start Finish Duration Depen-
Assigned To Duration Start Date Finish Date Date Date Variance dency Status

Project Manager 2024-03- 2024-03- Com-

(Ronnie) 1.8 weeks 2024-03-04 2024-03-31 04 31 - - pleted

Project Manager 2 days 1 2024-03- 2024-03- Com-

(Ronnie) hour 2024-03-04 2024-03-10 04 10 - - pleted

Business Analyst 4 days 2 2024-03- 2024-03- Com-

(Ronnie) hours 2024-03-11 2024-03-24 11 24 - 1.1 pleted

Project Manager 2 days 1 2024-03- 2024-03- Com-

(Ronnie) hour 2024-03-25 2024-03-31 25 31 - 1.2 pleted

Project Man- 2 days 1 2024-04- 2024-04- Com-

ager(Ronnie) hour 2024-04-01 2024-04-07 01 07 - 1.3 pleted

Project Man- 2 days 1 2024-04- 2024-04- Com-

ager(Ronnie) hour 2024-04-08 2024-04-14 08 14 - 1.4 pleted

In
Business Analyst progres
(Ronnie) 2.4 weeks 2024-04-15 2024-05-12 - - - - s

Business Analyst 4 days 2 Not

(Ronnie) hours 2024-05-13 2024-05-19 - - - 2 Started

Data Analyst 8 days 4 Not

(Ronnie) hours 2024-05-20 2024-06-02 - - - 2.1 Started

System Architect 4 days 2 Not

(Ronnie) hours 2024-06-03 2024-06-09 - - - 2.2 Started

System Architect Not

(Ronnie) 4.2 weeks 2024-06-10 2024-07-14 - - - - Started

System Architect 11 days 8 Not

(Ronnie) hours 2024-06-10 2024-06-23 - - - 3 Started

Database Engi- 5 days 9 Not

neer (Ronnie) hours 2024-06-24 2024-06-30 - - - 3.1 Started

UI/UX Designer 5 days 9 Not

(Ronnie) hours 2024-07-01 2024-07-07 - - - 3.2 Started

Business Analyst 5 days 9 Not

(Ronnie) hours 2024-07-08 2024-07-14 - - - 3.3 Started

Development Not
Team (Ronnie) 1.8 weeks 2024-07-15 2024-09-21 - - - - Started
System Adminis- 1 day 4 Not
trator (Ronnie) hours 2024-07-15 2024-07-21 - - - 4 Started

Front-end Devel- 4 days 2 Not

opers (Ronnie) hours 2024-07-22 2024-08-11 - - - 4.1 Started

Back-end Devel- 4 days 2 Not

opers (Ronnie) hours 2024-08-12 2024-09-01 - - - 4.2 Started

Database Engi- 2 days 8 Not

neers (Ronnie) hours 2024-09-02 2024-09-15 - - - 4.3 Started

QA Team (Ron- Not

nie) 1.8 weeks 2024-12-02 2025-01-13 - - - - Started

QA Team (Ron- Not

nie) 4 days 2024-12-02 2024-12-15 - - - 5 Started

QA Team (Ron- Not

nie) 2 days 2024-12-16 2024-12-22 - - - 5.1 Started

Development Not
Team (Ronnie) 4 days 2024-12-23 2025-01-05 - - - 5.2 Started

Network diagram
Ghant chart
Ghant chart

March April May

TASK NAME week1 week2 week3 week4 week1 week2 week3 week4 week1 week2 week3 week4

Planning

Analysis

Design

Implementa-
tion

Testing

Work plan
Task Estimated Estimated Estimated Depen-
ID Task Name Assigned To Duration Start Date Finish Date dency

Project Manager
1 Planning Phase (Ronnie) 1.8 weeks 2024-03-04 2024-03-31 -

Project Manager 2 days 1

1.1 Project Initiation (Ronnie) hour 2024-03-04 2024-03-10 -

Requirement Gathering Business Analyst 4 days 2

1.2 and Documentation (Ronnie) hours 2024-03-11 2024-03-24 1.1

Resource Identification Project Manager 2 days 1

1.3 and Allocation (Ronnie) hour 2024-03-25 2024-03-31 1.2

Project Timeline and Project Man- 2 days 1

1.4 Milestone Planning ager(Ronnie) hour 2024-04-01 2024-04-07 1.3

Budgeting and Cost Esti- Project Man- 2 days 1

1.5 mation ager(Ronnie) hour 2024-04-08 2024-04-14 1.4

Business Analyst
2 Analysis Phase (Ronnie) 2.4 weeks 2024-04-15 2024-05-12 -

User Interviews and Sur- Business Analyst 4 days 2

2.1 veys (Ronnie) hours 2024-05-13 2024-05-19 2

Data Collection and Data Analyst (Ron- 8 days 4

2.2 Analysis nie) hours 2024-05-20 2024-06-02 2.1

2.3 System Requirements System Architect 4 days 2 2024-06-03 2024-06-09 2.2

 Specification (Ronnie) hours

System Architect
3 Design Phase (Ronnie) 4.2 weeks 2024-06-10 2024-07-14 -

System Architecture De- System Architect 11 days 8

3.1 sign (Ronnie) hours 2024-06-10 2024-06-23 3

Database Design and Database Engineer 5 days 9

3.2 Schema Definition (Ronnie) hours 2024-06-24 2024-06-30 3.1

User Interface Design UI/UX Designer 5 days 9

3.3 and Wireframing (Ronnie) hours 2024-07-01 2024-07-07 3.2

Use Case, DFD Devel- Business Analyst 5 days 9

3.4 opment (Ronnie) hours 2024-07-08 2024-07-14 3.3

Development Team
4 Coding (Ronnie) 1.8 weeks 2024-07-15 2024-09-21 -

Development Environ- System Administra- 1 day 4

4.1 ment Setup tor (Ronnie) hours 2024-07-15 2024-07-21 4

Front-end Develop- 4 days 2

4.2 Front-end Coding ers (Ronnie) hours 2024-07-22 2024-08-11 4.1

Back-end Develop- 4 days 2

4.3 Back-end Coding ers (Ronnie) hours 2024-08-12 2024-09-01 4.2

Database Engi- 2 days 8

4.4 Database Programming neers (Ronnie) hours 2024-09-02 2024-09-15 4.3

Testing and Quality As-

5 surance QA Team (Ronnie) 1.8 weeks 2024-12-02 2025-01-13 -

5.1 System Testing QA Team (Ronnie) 4 days 2024-12-02 2024-12-15 5

User Acceptance Test-

5.2 ing QA Team (Ronnie) 2 days 2024-12-16 2024-12-22 5.1

Bug Fixing and Issue Development Team

5.3 Resolution (Ronnie) 4 days 2024-12-23 2025-01-05 5.2

Budget
Task
ID Task Name Estimated Cost (UGX)

1 Planning Phase 153,000

1.1 Project Initiation 25,500

1.2 Requirement Gathering and Documentation 51,000

1.3 Resource Identification and Allocation 25,500

1.4 Project Timeline and Milestone Planning 25,500

1.5 Budgeting and Cost Estimation 25,500

2 Analysis Phase 204,000

2.1 User Interviews and Surveys 51,000

2.2 Data Collection and Analysis 102,000

2.3 System Requirements Specification 51,000

3 Design Phase 610,500

3.1 System Architecture Design 210,000

3.2 Database Design and Schema Definition 133,500

3.3 User Interface Design and Wireframing 133,500

3.4 Use Case, DFD Development 133,500

4 Coding 172,500

4.1 Development Environment Setup 31,500

4.2 Front-end Coding 51,000

4.3 Back-end Coding 51,000

4.4 Database Programming 39,000

5 Testing 127,500

5.1 System Testing 51,000

5.2 User Acceptance Testing 25,500

5.3 Bug Fixing and Issue Resolution 51,000

Total Estimated Project Cost 1,063,500

3. Developing a Business Case for a CRMS

a. Application Domain:
Functional Requirements:
• The CRMS should allow officers to create records for incidents, suspects, victims, and
witnesses.
• It should provide efficient search and retrieval capabilities based on criteria such as case
number, date, and location.
• The system should generate reports and support data analytics.
Non-Functional Requirements:
• The CRMS should ensure data security, restricting unauthorized access.
 • It should respond fast to search queries.
• The system should scale effectively to handle increasing data volume.
• User interfaces should be intuitive and user-friendly.
User Requirements:
Officers:
• The system should facilitate easy data entry.
• It should have an intuitive interface for record creation.
• Quick search and retrieval should be available.
Investigators:
• Advanced search capabilities should be provided (e.g., by suspect name, location, date).
• Customizable reports should support analysis.
Administrators:
• User management features (add, edit, delete users) should be included.
• Access control (assigning roles and permissions) should be part of the system.
Business Requirements:
• The CRMS should improve efficiency by reducing manual paperwork.
• It should enhance accuracy in record keeping.
• Transparency should be achieved through accessible data.
System Requirements:
Hardware Requirements:
The CRMS should run on hardware that meets the following specifications:
Server:
• Multi-core processor (Intel Xeon ,AMD Ryzen or better) with sufficient processing power.
• Sufficient RAM (8 GB or more) to handle concurrent user requests.
• Adequate storage (1TB SSD or more) for the database and system files.
Client Devices:
• Standard desktop or laptop computers for officers and investigators.
• Mobile devices (tablets or smartphones) for field officers.
Operating System:
The CRMS should be compatible with the following operating systems:
Server:
• Linux (e.g., Ubuntu, CentOS) or Windows Server.
Client Devices:
• Windows (Windows 10 or later) or mac OS.
Software Dependencies:
The CRMS should rely on the following software components:
Web Server:
• Django
• Database Management System (DBMS):
• MySQL, PostgreSQL, or another relational database system.
Programming Languages and Frameworks:
• python (for server-side scripting).
• JavaScript (for client-side interactions).
• HTML/CSS (for user interfaces).
• Bootstrap or other front-end frameworks.
Network Requirements:
The CRMS should operate within the following network parameters:
Local Area Network (LAN):
• High-speed LAN connectivity for internal communication.
Internet Access:
• If the system needs external data (e.g., criminal history databases), ensure internet access.
Firewall Rules:
• Configure firewall rules to allow necessary traffic (HTTP/HTTPS).
b. Analysis of Benefits:
Tangible Benefits:
• Reduced time spent on paperwork and data entry
• Improved case investigation and solving rates
• Enhanced information sharing and collaboration
• More efficient resource allocation
• Reduced storage costs for paper records
Intangible Benefits:
• Improved public safety through better crime management
• Increased transparency and accountability within law enforcement
• Enhanced officer safety through better access to criminal history information
c. Analysis of Costs:
Tangible Costs:
• Software purchase or development
• Hardware infrastructure
• System implementation and training
• Ongoing maintenance and support
Intangible Costs:
• Potential for user resistance to change
• Risk of data security breaches
d. User Issues:
• Skills: Law enforcement personnel may require training on how to use the CRMS
effectively.
• Adoption Effort: Change management strategies will be needed to encourage officers to
adopt the new system.
e. Risk Assessment:
• Technical Risks: System downtime, data security breaches, software bugs.
• Organizational Risks: Resistance to change from users, lack of IT support, poor data quality.
• Other Risks: Legal and privacy concerns surrounding data storage.
Narrative Use cases
Use case Name: User Registration Id: 1 Priority: High
Actor: Admin
Description:
• A new police staff is registered into the system by filling in a form with username and
password that will later be used when logging into the system.
Trigger: System Admin
Preconditions:
 The staff must not have an account yet.
 The staff must have strong password and a username
Normal course: Information for steps:
1. The admin logs into the system and ➔ System Validates admin username and
clicks register users button. password.
2. The register form is displayed and the ➔ The system validates form fields
admin fills in the username and
password for new staff
3. The admin clicks on register button ➔ A success message is displayed

Alternative course: Information for steps:

None None
Post Conditions:
• The staff is successfully registered into the system.
Exceptions:
 • if a weak password is a signed to the new staff, the system notifies the admin to assign
strong password.
Summary Inputs Source Outputs Destination
Username, password Admin Successfully System Database
registered

Use case Name: User Login Id: 2 Priority: High

Actor: System Admin, Support staff, O/C
Description:
• This is a gate keeper measure used to prevent unauthorized access into the system. Only
users with the correct username and password can access the control dashboard. Some
functionalities of the system are hidden from different categories of users
Trigger: Admin, Support staff, O/C
Preconditions:
 The User must be registered in the system in order to login
Normal course: Information for steps:
1. The User types the system URL ➔ The browser loads the system
2. The user fills in the user name and ➔ System Validates the username and
password. password.
3. The user clicks on the log in button ➔ A success message is displayed
Alternative course: Information for steps:
None None
Post Conditions:
• The user is successfully logged into the system.
Exceptions:
• If the user enters wrong password or username, the system notifies the user by displaying
error message and the user will not be allowed to access pages of the system
Summary Inputs Source Outputs Destination
Username, password Admin Successfully System Database
registered
Design
Use case Diagram

Crime Record management System

View crimes
investigator

Report Crime

Login
Arresting officer
Complainant

Track case status

Assign Case to staff

Administrator

Assign staff roles

O/C

Register staff

Context Diagram

View Reported Crimes

Complainant

Complainant Login
investigator

Report crime
Support staff login

0
View suspects CRIME RECORD
MANAGEMENT SYSTEM

Report Crime
O/C login
Asign roles to
users

Administrator Login
O/C
Systems
administrator
View cases
Register new user
 Level 1 Diagram Logged in Administrator

Logged in Complainant
User registration prompt
Administrator

Complainant
3.0 Success / failure response displayed
Initiating crime reporting Assign staff role

Success / failure response triggered

Generated reference

4.0 Form Validation

Request to update user role
Report Crime

D1 User Records

D2 Criminal records
Success / failed crime report response

Logged in O/C
Validation check
Logged in support staff

View request record/error returned

O/C 5.0
View cases

Cases displayed Support Staff

Request to view assigned case

Assigned case is displayed

System Architecture

Request

Response

Request

Request

Data

Response

Client Internet Server Database

Entity Relationship diagram

wireframes
Story Board

Implementation
The following are the images of the implemented system.
Home page
References
[1] Khan, A., Singh, A., Chauhan, A. and Gupta, A., 2019. Crime management
system. International Research Journal of Engineering and Technology (IRJET), 6(04).
[2] Hisham, A., Ahmed, A., Khaled, M., Abdullatif, N. and Kassem, S.S., 2021. Modelling of Crime
Record Management System Using Unified Modeling Language. Ingénierie des Systèmes d
Inf., 26(4), pp.365-373.