0% found this document useful (0 votes)
11 views6 pages

wb3 Draft

The document describes the proposed methodology for developing a crime reporting portal. It discusses the application architecture, including the user interface, crime reporting and backend modules, and a MySQL database. It also outlines the phases of the waterfall design process that will be followed, including functional requirements, system design, and the modules that will compose the reporting system.

Uploaded by

Owoeye Shina
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
11 views6 pages

wb3 Draft

The document describes the proposed methodology for developing a crime reporting portal. It discusses the application architecture, including the user interface, crime reporting and backend modules, and a MySQL database. It also outlines the phases of the waterfall design process that will be followed, including functional requirements, system design, and the modules that will compose the reporting system.

Uploaded by

Owoeye Shina
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 6

CHAPTER THREE

METHODOLOGY

3.1 INTRODUCTION

The advantages of a crime reporting system and the need to incoporate it to

government establishments has been discussed in the previous chapters, this project

main goal is to is to develop a crime reporting portal with civil service personnels as

its target audience and add a very great and soley effective witness protection features

especially for people that would like to report bud do not do so out of the fear of being

stigmatized.

This chapter gives insights to how components connect, hierachy of reporting,

how the application was designed and the whole crime reporting system as a whole.

3.2 PROPOSED DESIGN

The architecture will determine significantly the mode of operation and also

the the outcome of the system thereby saving time and energy in the development

phase. The waterfall model will be used. Waterfall follows a linear and sequential

approach, where each phase (requirements, design, implementation, testing,

deployment) is completed before moving to the next.

3.2.1 APPLICATION ARCHITECTURE

The architecture will consist of the user interface, the crime reporting module

(which can be accessed after authentication from the user interface page), the

backend services that provides functionality such as data processing, storage, and

business logic. And a MySQL database management system for storage. Also a

notification system that sends alerts and updates to users, investigators, and

administrators will be included.


3.2.2 FRONT END

The proposed system architecture can be found below.

APPLICATION LAYER (DATA REPORT MODULE


ACCESS + BUSINESS LOGIC)

ACCESS MODULE
DATABASE

USER 1 USER 2 USER n

The user interface is the front-end component where users interact with the system. It

includes web pages or mobile applications through which users can report crimes,

view crime statistics, track their reports, and communicate with law enforcement

agencies.

HTML will be used for the web design structure and CSS (cascading style sheet while

Javascript will be used for client side purposes.


3.3 PHASES OF THE DESIGN

The model we will use is the waterfall model; waterfall follows a linear and

sequential approach, where each phase (requirements, design, implementation,

testing, deployment) is completed before moving to the next. Requirements are

defined upfront, and changes are often challenging to accommodate once the project

is underway. The sequence of waterfall model used is discussed as follows:

3.3.1 FUNCTIONAL REQUIREMENT

The basic functions the system should perform includes:

1. Signup as anonymous or login using a unique id

2. Register a complaint and note the unique id

3. Follow up on report status usind the prior id

USE CASE DIAGRAM

SYSTEM DESIGN

The system requirement specifications of existing systems gives us an insight for the

system design, which is an improvement over the prior. Tools used for these are PHP,

MySQL and javascript.

3.4 ELEMENTS OF THE PROPOSED SYSTEM

The Flowchart is a pictorial representation that captures the main activities of

users on the system, starting from the point of gaining access to the system to the last

main activity of the system. The process flowchart can be seen below.

START

NEW
USER?
The flowchart can be explained thus:

 The application should have a user friendly interface where the crimes can be
reported
 The application should make provisions for the uploads of multimedia files, in
case users have evidences to back their reports
 The user should be able to choose whether to report with a known identity or as
anonymous
 There will be two levels of administrators for this platform
 Level 1 admin reviews reviews reports that are not too serious or that do not need
feedback
 In the case the report is a very serious one or that needs a necessary feedback, the
report is transferred to the admin on level 2
 Level 2 admin(who in this case is either the head off service or someone working
with him that is of high trust) gives feedbacks and gives rewards for complaints
where necessary
 Visitors be should able to view the summary of resolved reported offences, this
will further motivate them to drop theirs too, in case they might have.
3.4.2 MODULES

The reporting system consists of modules to perform different functions with

various sub levels. The modules are lised as follows;

1. The admin module: the reports/complaints are submitted to be reviewed by the

admin. There will be two levels of administrators for this platform:

Level 1 admin reviews reviews reports that are not too serious or that do not need

feedback. In the case the report is a very serious one or that needs a necessary

feedback, the report is transferred to the admin on level 2. Level 2 admin(who in this

case is either the head off service or someone working with him that is of high trust)

gives feedbacks and gives rewards for complaints where necessary

The diagram below shows the flow of information during reports.


REPORT ADMIN LEVEL 1
FROM USER

ADMIN LEVEL 2

2. The USER module:

There is a user friendly interface where the crimes can be reported, users can decide to

register as anonymous or with known identities. With emphasis on witness protection,

the anonymousness will be very guaranteed thereby breaking this module into 2

submodules:

The anonymous submodule:

Below is a use case statement for users who wish to register as anonymous

SN User Action System


1 Sign up Accept registration
2 Report an incident Generate a code for
tracking progress
3 Check resolved reports, Return appropriate text
containing MDA affected and media(if available) for
and items recovered the selected
context.

The known identity submodule:

A use case statement for a known registered user can be described below

S/N User Action System


1 Sign up using known Accept Registration
details e.g name, MDA,
address, etc. A username
and password is created
during this process
2 Report an incident of Generate a code for
misappropriation, tracking progress and link
uploading files to support it with the user’s
evidences information in the database

3 After some time, login Displays the status of the


using the sign up details report as ‘processed’ or
and check the progress of ‘pending’, If it is
the report processed, a view button
will be enabled to make
the user see the remark of
the report and if a reward
is stated
4 If they wish, users can file Generate another tracking
another report code and link it with the
report made under the
user’s profile in the
database

You might also like