Project
Course Title: Software Design and Architecture
SECTION: 5th (B)
Submitted By:
Ali Kumail Raza — Roll No. 23014198-120
Shayan Arshad — Roll No. 23014198-110
Shawaiz Ali — Roll No. 23014198-079
Saif Ul Islam — Roll No. 23014198-092
Submitted To:
Ms. Shaista
1. Introduction
1.1 Purpose
The purpose of this document is to present a detailed description of the Criminal
Management System (CMS). This software is designed to modernize the
traditional manual file-keeping systems used in police stations. By digitizing
records, the system aims to streamline the process of registering First Information
Reports (FIRs), tracking criminal profiles, and managing case histories. This
document covers the system’s scope, functional requirements, and technical
constraints to guide the development and deployment process.
1.2 Scope
The Criminal Management System is a web-based application developed using the
[Link] framework. It serves as a centralized platform for police administrators to
manage law enforcement data efficiently.
The core scope of the project includes:
Digital FIR Registration: Moving from paper-based complaints to a secure digital
database.
Criminal Profiling: Maintaining a searchable registry of criminals, including
personal details and crime history.
Case Tracking: Monitoring the legal status of cases linked to specific criminals.
Administrative Dashboard: A "Lucifer" command center for quick navigation
between modules.
Report Generation: providing summary data for decision-making.
1.3 Definitions, Acronyms, and Abbreviations
SRS: Software Requirement Specification.
CMS: Criminal Management System.
FIR: First Information Report (a document prepared by police when they receive
information about a cognizable offense).
Admin: The system administrator or police officer with authorized access.
GUI: Graphical User Interface.
1.4 References
IEEE Std 830-1998: IEEE Recommended Practice for Software Requirements
Specifications.
Assignment Guidelines: Semester-End Project Requirements.
1.5 Overview
This document is organized into specific sections. Section 2 provides a high-level
overview of the system environment and user characteristics. Section 3 details the
specific functional features (like FIR and Criminal modules). Section 4 outlines the
interface requirements, and Section 5 defines the non-functional attributes such
as security and performance.
2. Overall Description
2.1 Product Perspective
Currently, many local stations rely on physical files, which are prone to damage,
loss, and slow retrieval speeds. The Criminal Management System acts as a
replacement product, offering a secure web interface. It runs on a server-client
model where the data is stored centrally in a SQL database and accessed via a web
browser by authorized personnel.
2.2 Product Functions
Based on the administrative dashboard design, the system performs the following
major functions:
Dashboard Management: Provides a grid-view of all available operations.
Registration Services: Allows for the entry of new FIRs and Criminal Profiles.
Record Retrieval: Enables the viewing of "Criminal Lists" and "FIR Lists".
Case Management: Handles the lifecycle of a legal case.
System Navigation: Provides seamless linking between different administrative
modules.
2.3 User Classes and Characteristics
The Administrator (Police Operator): This user is an authorized official
responsible for data entry. They are expected to have basic computer literacy.
Their main goal is to enter data accurately and retrieve records quickly during
investigations.
2.4 Operating Environment
Server: Windows Server running IIS (Internet Information Services).
Framework: .NET Framework ([Link] Web Forms).
Database: MS SQL Server.
Client: Any standard web browser (Google Chrome, Firefox, Microsoft Edge).
2.5 Constraints
Interface Design: The system must adhere to a specific color theme (Dark
Slate/Green palette: to maintain a professional, serious look appropriate for law
enforcement software.
Connectivity: The system requires a continuous network connection to the central
database server to function.
2.6 Assumptions and Dependencies
It is assumed that all workstation computers in the station are equipped with a
modern web browser.
The system depends on the [Link] and [Link] libraries for
proper data handling and routing.
3. System Features
3.1 Feature 1: Administrative Dashboard
Description: The dashboard serves as the landing page after login. It is designed
for clarity, featuring a "Welcome to Lucifer" greeting and a grid of large, touch-
friendly buttons for easy access.
Inputs: Mouse clicks on navigation buttons (e.g., "Register New Criminal", "View
FIRs").
Outputs: Redirection to the specific functional module requested.
Constraints: The layout must automatically adjust to the screen size, maintaining
a 3-column grid structure.
3.2 Feature 2: FIR Management (Registration & Listing)
Description: This feature allows the officer to record the details of a crime
immediately. It also allows them to view a history of all registered complaints.
Inputs: Complainant Name, Incident Date/Time, Place of Incident, Description of
Crime, Suspect Details.
Outputs: A unique FIR ID is generated, and the record is saved to the database.
The "View FIRs" page displays a tabular list of these records.
Processing: The system validates that all mandatory fields (like Date and
Description) are filled before saving.
3.3 Feature 3: Criminal Record System
Description: A core security feature that creates a digital dossier for arrested
individuals.
Inputs: Criminal Name, Alias, Age, Gender, Physical Marks, Associated Crimes,
Photograph.
Outputs: A stored profile that can be updated or retrieved later via the "Criminal
List" button.
Processing: Data is cross-referenced to ensure duplicate profiles are not created
for the same individual.
3.4 Feature 4: Case Management
Description: This module links the FIR and the Criminal to the legal system. It
tracks the progress of the case through the courts.
Inputs: Case Number, Court Name, Hearing Date, Judge Name, Current Status
(Pending/Closed).
Outputs: A status report of the case accessible via [Link].
3.5 Feature 5: Reporting Module
Description: Enables the admin to generate summaries, such as the total number
of FIRs filed in a month or a list of most active criminals.
Inputs: Date range selection or specific crime category filters.
Outputs: A structured table or printable view of the requested data.
4. External Interface Requirements
4.1 User Interface (UI)
The user interface is designed to be minimalist and distraction-free:
Header: A persistent header displays "Criminal Management System - Admin" to
provide context.
Navigation Bar: A dark grey bar (#354f52) containing links to major modules and
a "Logout" option is visible on every page.
Interactive Elements: Buttons change color (hover effect) to #1e7168 to provide
visual feedback to the user.
Typography: The font family is set to Arial for maximum readability.
4.2 Hardware Interface
Server: Requires a machine capable of running SQL Server and IIS with at least
8GB RAM.
Client: Optimized for standard desktops with a minimum resolution of 1366x768.
4.3 Software Interface
Operating System: Designed for Windows-based hosting environments.
Back-End: C# .NET.
Front-End: HTML5, CSS3, [Link] Web Forms.
4.4 Communication Interface
The system utilizes HTTP/HTTPS protocols to transmit data securely between the
browser and the web server.
5. Non-Functional Requirements
5.1 Performance
Response Time: The dashboard and forms are optimized to load within 2-3
seconds on a standard office network.
Throughput: The system is capable of handling simultaneous data entry from
multiple terminals without data corruption.
5.2 Security
Authentication: Access is strictly controlled. Only users with valid credentials can
access the [Link] dashboard.
Session Management: The system includes a "Logout" feature to ensure sessions
are closed when the user steps away.
5.3 Reliability
Availability: The system is designed for 24/7 operation, critical for police
environments.
Data Integrity: Validation checks prevent incomplete or erroneous data (like text
in date fields) from entering the database.
5.4 Usability
Ease of Learning: The interface uses clear, non-technical labels (e.g., "Register
FIR" instead of "Insert Record"), allowing officers to learn the system with minimal
training.
Consistency: All pages share the same header, footer, and navigation style.
USE CASE DIAGRAM
CLASS DIAGRAM
Activity Diagram