EXPERIMENT-2

AIM : Write the SRS (Software Requirement Specification) for an application.

Theory :
A Software Requirements Specification (SRS) is a detailed document that outlines the
system’s functional and non-functional requirements. It acts as a formal agreement between
stakeholders and developers, ensuring that all parties understand what the system will do and
how it will be built.
For a Crime Management System, the SRS helps define how various modules—like crime
logging, FIR registration, case tracking, and evidence management—interact. It lays the
foundation for system design, development, and testing, especially when implemented in a
relational database using SQL.

Procedure :
To write the SRS for the Crime Management System:
1. Introduction
o Purpose: To digitalize and streamline the crime recording and investigation
process.
o Scope: The system handles crime records, FIR filing, case tracking, evidence
management, and report generation.
o Users: Police officers, admin, victims, witnesses, and forensic staff.
2. Overall Description
o Product Perspective: It is a standalone web-based application integrated with a
database.
o Product Functions:
• Register crime details
• File FIRs
• Track cases
• Store and retrieve evidence
• Generate analytical reports
o User Characteristics: Users vary from technically trained officers to general
admin users.
o Constraints: Secure data access, system availability, performance under load.
o Assumptions: All users will have login credentials, internet access, and
authorization levels.
 3. Functional Requirements
o FR1: The system shall allow officers to register a new crime.
o FR2: The system shall allow the admin to assign officers to cases.
o FR3: The system shall allow victims to file FIRs online.
o FR4: The system shall store, update, and delete evidence linked to a case.
o FR5: The system shall allow generating crime reports filtered by type,
location, or status.
4. Non-Functional Requirements
o NFR1: System must respond within 3 seconds for 95% of requests.
o NFR2: All data must be stored in encrypted format.
o NFR3: System must be available 99.9% of the time.
o NFR4: Must support up to 1000 concurrent users.
o NFR5: Interface should be accessible on desktop and mobile browsers.
5. External Interface Requirements
o GUI: Interactive web pages with forms for input and tables for report display.
o Database: MySQL to store and manage crime-related data.
o Security: Role-based access control, audit logs, and session timeouts.

SRS Document :
1. Introduction
1.1 Purpose
To provide a clear and complete definition of the functionalities, database entities,
relationships, and constraints for a Crime Management System.
1.2 Scope
The system manages data related to crimes, criminals, victims, witnesses, police officers,
FIRs, and case details. It ensures secure storage, efficient retrieval, and proper linking of
associated information.
1.3 Intended Audience
 Database developers
 Project supervisors
  Law enforcement software users
1.4 Definitions and Acronyms
 FIR: First Information Report
 DBMS: Database Management System
 SQL: Structured Query Language
 CRUD: Create, Read, Update, Delete

2. Overall Description
2.1 Product Perspective
This is a database-only backend component, designed for future integration with a user
interface.
2.2 Product Functions
 Log and update crime reports
 Track individuals involved (criminals, victims, witnesses)
 Maintain FIR and case details
 Store and link evidence to cases
2.3 User Classes
 Admin: Full access to all database operations
 Officer: Views FIRs and cases assigned
 Clerk/Staff: Assists in data entry and updates
2.4 Operating Environment
 MySQL database engine
 SQL Workbench / MySQL Workbench
 OS: Windows/Linux
2.5 Constraints
 Data types and constraints must be followed strictly
 Proper use of ENUM, AUTO_INCREMENT, and FOREIGN KEY
 ON DELETE rules to maintain referential integrity

3. Specific Requirements
3.1 Functional Requirements
  FR1: The system must store officer, victim, witness, and criminal records
 FR2: It must record crime information and link it with related persons
 FR3: It must register FIRs and track cases
 FR4: It must associate evidence with respective cases
3.2 Non-Functional Requirements
 NFR1: Maintain data consistency with foreign keys
 NFR2: Allow scalability for future module integration
 NFR3: Ensure that queries run efficiently for large datasets

4. Database Overview
Tables Created:
 P_officer
 witness
 victim
 criminals
 crime
 FIR
 case_details
 evidence
Each table uses primary keys, and relevant foreign keys, with proper cascading and null-
handling rules.

Conclusion: This SRS provides a detailed structure of the Crime Management Database
System. It clearly defines how crime-related data is to be stored, linked, and accessed using
relational database design. By following this specification, developers can build a robust and
scalable backend system that serves as the foundation for a full-fledged crime tracking and
investigation support platform.
 EXPERIMENT-3

Aim: To identify various elicitation techniques and their usage for gathering requirements
for the Crime Management Database System.

Theory :
Requirement Elicitation is the process of collecting the requirements of a system from
stakeholders like end users, customers, or subject matter experts. It is a foundational step in
software development and is crucial for building a system that meets the user’s needs.
There are several elicitation techniques, each with different strengths and use-cases. Common
techniques include:
 Interviews – One-on-one discussions to gather detailed information.
 Questionnaires – Structured forms with open or closed questions to collect data from
many users.
 Brainstorming – Group sessions to generate ideas and identify system expectations.
 Observation – Watching how users currently perform tasks to identify needs and pain
points.
 Document Analysis – Reviewing existing documents, reports, and systems for
insights.
 Workshops – Facilitated sessions that bring stakeholders together to define
requirements collaboratively.
Selecting the appropriate technique depends on factors like stakeholder availability,
complexity of the system, and time constraints.

Procedure :
1. Conducted interviews with police officers and admin staff to understand their routine
tasks and expectations from the system.
2. Prepared questionnaires for victims and witnesses to understand user experience and
feedback needs.
3. Observed current paper-based crime reporting and FIR filing processes to identify
pain points.
4. Reviewed existing legal documentation and formats used by police departments.
5. Organized a brainstorming session with developers and security consultants to gather
technical requirements like data encryption and access control.
6. Created a basic prototype of the system dashboard to validate functional requirements
with the end users.
Elicitation :
1. Interviews
Usage:
 Conducted with police officers, investigators, and administrative staff to understand
current manual processes.
 Helped identify key entities like FIR, crime, officer, victim, and evidence.
Outcome:
 Realized the need for linking FIR to both crime and officer.
 Importance of tracking case status over time.

🔹 2. Questionnaires
Usage:
 Distributed to multiple law enforcement staff and record keepers.
Outcome:
 Revealed common data entry points (e.g., victim age, location of crime).
 Confirmed requirements for features like status tracking and automated linking
between entities.

🔹 3. Observation
Usage:
 Observed record-keeping in police stations and how crime cases are physically stored.
Outcome:
 Identified redundancy in paper records.
 Inspired digital structure like evidence and case_details.

🔹 4. Document Analysis
Usage:
 Reviewed existing FIR templates, case files, and crime logs.
Outcome:
 Helped define fields like report_date, station, and description.
  Led to inclusion of ENUM fields like crime status and case status.

🔹 5. Workshops
Usage:
 Organized with IT professionals and police administrators to define relationships
between entities.
Outcome:
 Created consensus on database structure.
 Helped prioritize the features like deletion policies (ON DELETE CASCADE) and
transaction flow (from crime → FIR → case).


Conclusion
A combination of elicitation techniques was essential in capturing complete and
accurate requirements for the Crime Management System. Interviews and document
analysis provided core structural needs, while questionnaires and workshops ensured
usability and clarity. By applying these techniques, the database design now aligns
well with real-world law enforcement workflows, ensuring practicality, reliability,
and efficiency in tracking and managing crime records.
 EXPERIMENT-4

AIM :To classify the requirement into functional and non functional requirements.
Theory :
In software engineering, understanding and organizing requirements is crucial for building a
reliable system. Requirements are broadly classified into two types:
Functional Requirements (FR):
These specify what the system should do — the core operations, features, and behavior.
They are often represented as use-cases or system tasks.
Non-Functional Requirements (NFR):
These specify how the system should behave — including performance, reliability,
scalability, usability, and constraints. NFRs affect the user experience and technical quality
of the system.
This classification helps developers, testers, and stakeholders clearly understand expectations
and plan implementation effectively.

1.Functional Requirements :
FR1 The system should allow storage and retrieval of police officer records.

FR2 The system should manage details of victims, criminals, and witnesses.

The system should allow creation and linking of crimes with victims, witnesses, and
FR3
criminals.

FR4 The system must support FIR creation associated with specific officers and crimes.

FR5 The system should allow case tracking with status updates and final verdicts.

FR6 The system should store and associate evidence with respective cases.

FR7 Relationships must be maintained between all entities using foreign keys.

FR8 Data should be modifiable and deletable using proper constraints and cascades.

2.Non-Functional Requirements :

NFR1 The system should maintain data integrity using primary and foreign key constraints.
NFR2 The database should be scalable to accommodate growing data volume.

NFR3 The system should provide quick query response time (performance).

The system should follow security best practices, such as access controls (in future
NFR4
integration).

NFR5 It should be compatible with MySQL and SQL Workbench environments.

NFR6 System structure should be modular and maintainable for future development.

NFR7 Must handle null values and deletions gracefully to avoid broken relationships.

Conclusion :
By classifying requirements into functional and non-functional, we gain a deeper
understanding of both the system’s capabilities and its expected quality standards. The
functional requirements ensure that all necessary operations are covered, while the non-
functional requirements set the baseline for system performance, reliability, and future
scalability. This classification lays the foundation for successful implementation and testing
of the Crime Management Database.
 EXPERIMENT-5

AIM : To perform the Requirement analysis of the specified problem and draw a flowchart.

Theory :
Requirement Analysis is the process of understanding and documenting what a system should
do. It involves identifying the inputs, processes, and outputs of the system and organizing
them into clear functional modules.
The main steps in requirement analysis are:
1. Identifying Stakeholders
2. Defining Functional Modules
3. Understanding Data Flow
4. Determining System Inputs and Outputs
5. Breaking Down the System into Subsystems
Flowcharts are then used to visually represent the process flow and logic of the system. A
flowchart uses standard symbols like ovals (start/end), rectangles (process), diamonds
(decisions), and arrows (flow direction) to make system behavior easier to understand.

Requirement Analysis:
🔹 Stakeholders:
 Police Officers
 Administrative Staff
 Victims/Witnesses
 System Admin

🔹 Major Functional Modules:

1. Police Officer Management
2. Victim, Witness, and Criminal Management
3. Crime Record Entry
4. FIR Registration
5. Case Tracking
 6. Evidence Storage

🔹 Inputs:
 Officer details, victim details, witness statements, criminal records, FIR details,
evidence
🔹 Processes:
 Recording data into tables
 Linking records using IDs
 Updating status of crimes and cases
🔹 Outputs:
 Complete crime report
 Case status
 Evidence trail
 Officer activity

Conclusion :

Through requirement analysis, we broke down the Crime Management System into well-
defined functional modules. Identifying the inputs, processes, and outputs allowed us to
understand the overall system behavior. The flowchart visually represents the core processes
of the system, helping in documentation, implementation, and communication with
stakeholder
 EXPERIMENT : 6
AIM : TO Draw the ER Diagram with generalization, specialization and aggregation of a
specified problem statement.

Theory:
An EER Diagram is a enhanced of entities, version of Entity relation digram with attributes,
and their relationships in a database. It is used in database design to organize data and
understand how various components relate to each other.
This digram shows Generalization, Specialization of those attributes.
Key Concepts Used:
1. Entity: A real-world object (e.g., Crime, FIR, Officer)
2. Attribute: Properties of an entity (e.g., name, age, location)
3. Relationship: Association among entities (e.g., registers, assigned_to)
4. Generalization: Combining similar entities into a generalized super-entity.
5. Specialization: Creating sub-entities from a general entity to represent more specific
features.
6. Aggregation: Treating a relationship as a higher-level entity (used when one relationship
is involved in another).

Procedure :
We identified the core entities in the Crime Management System such as Person, Crime, FIR,
Case, and Evidence.
Using generalization, we combined Officer, Victim, Witness, and Criminal into a general
Person entity.
Using aggregation, we modeled the Case as a higher-level abstraction involving Officer and
Crime.
Specialization was used to differentiate specific roles (like Officer and Victim) from the
general Person.
Digram :

Learning Outcomes:

 Understood how to design a complex ER model using generalization, specialization,

and aggregation.
 Practiced identifying abstract entities and designing their relationships effectively for
a real-world database application.
 EXPERIMENT-8
AIM : To convert the Data Flow Diagram (DFD) of the Crime Management System into a
structure chart.

Theory:
A structure chart is a top-down modular design representation that describes the hierarchical
organization of modules in a software system. It shows how a system is broken down into
different modules and how they interact through control and data flow. It is derived from the
DFD and helps in system implementation.
Key Features of a Structure Chart:
 Shows module hierarchy
 Emphasizes modularity and separation of concerns
 Arrows indicate data/control flow between modules

Procedure:
Based on our Level 1 DFD, we break the Crime Management System into these modules:
1. Crime Management System (Main Module)
2. ├── Manage User Data
│ ├── Add Officer
│ ├── Add Victim/Witness/Criminal
├── Register Crime
├── Generate FIR
├── Create Case
│ ├── Assign Officer
├── Store Evidence
└── Generate Reports
Each sub-module handles a specific function and may interact with a database table
accordingly.
Diagram: (Structure Chart) :
Learning Outcomes:
 Understood how to derive a structure chart from a DFD.
 Identified and separated system functionalities into well-defined modules.
 EXPERIMENT-7
AIM :
To draw different levels of Data Flow Diagrams (DFDs) for the Crime Management System.

Theory (In General):

A Data Flow Diagram (DFD) is used to visually represent the flow of data within a system. It
maps how information moves between processes, data stores, and external entities.

 Level 0 DFD (Context Diagram): Shows the system as a single process interacting
with external entities.
 Level 1 DFD: Breaks the system into major subprocesses and data stores.
 Level 2 DFD: Provides further detail by decomposing Level 1 processes into sub-
processes.

Procedure :
We identified the primary entities and processes of the Crime Management System such as
Manage Users, Register Crime, Create FIR, Register Case, Collect Evidence, and Generate
Reports.
We created a Level 0 diagram showing external entities like Police Officer, Victim, Witness,
and Admin.
Then we expanded this into a Level 1 DFD that introduced key system processes and their
interactions with data stores (e.g., Crime DB, Officer DB).
Finally, we detailed one process (e.g., Register Crime) in Level 2 to show granular data flow
between sub-processes.

Digram :
Level 0 :
Level 1:

Level 2:
Learning Outcomes:
 Learned how to break down a system into hierarchical DFD levels for better
understanding and design clarity.
 Practiced mapping the logical flow of data between system components and entities.
 EXPERIMENT-9
AIM :
To draw a Use Case Diagram for the Crime Management System.

Theory :
A Use Case Diagram is part of the Unified Modeling Language (UML) and is used to
represent the functional requirements of a system from a user perspective. It describes how
various actors interact with the system through use cases (functionalities).
Key Components:
 Actors: Users or other systems that interact with the application.
 Use Cases: Functionalities or services the system provides.
 Relationships: Associations between actors and use cases (include, extend,
generalization).

Procedure (Specific to Our System):

We first identified the major actors in the Crime Management System:
 Police Officer
 Victim
 Witness
 Admin
 Criminal (read-only/recorded)
Then, we identified the main use cases for each actor:
 Register Crime
 File FIR
 View FIR
 Create Case
 Assign Officer
 Update Case Status
 Add Evidence
 Generate Reports
We mapped each actor to their relevant use cases and grouped use cases logically under
Admin and Officer roles. Relationships such as include (e.g., Register Crime → File FIR)
were applied where one use case logically includes another.

Digram :
Learning Outcomes:
 Gained hands-on experience designing a use case diagram to
capture user interaction.
 Identified actors and grouped functionalities for system planning
and development.
 EXPERIMENT-10
AIM :
To estimate the project metrics using all COCOMO models for the Crime Management
System.

Theory :
COCOMO (Constructive Cost Model) is a software estimation model used to predict the
effort, cost, and schedule required for software development. It uses the number of lines of
code (KLOC) and other project attributes to estimate:
 Effort (person-months)
 Development Time (months)
 People required
Types of COCOMO Models:
1. Basic COCOMO: Calculates effort based on KLOC using a simple formula.
2. Intermediate COCOMO: Adds cost drivers (product, personnel, project attributes).
3. Detailed COCOMO: Breaks the project into modules and applies Intermediate
COCOMO to each.
Formulas:
Basic Model:
Effort = a × (KLOC)^b
Time = c × (Effort)^d
Where a, b, c, d are constants based on project type (organic, semi-detached, embedded)

Procedure :
1. We assumed the size of the Crime Management System to be approximately 10
KLOC (10,000 lines of code).
2. We applied the Basic, Intermediate, and Detailed COCOMO models:
o Basic: Using the standard formulas and constants for organic type.
o Intermediate: Considered cost drivers like required reliability, database size,
personnel capability, etc.
o Detailed: We divided the system into modules (FIR, Crime Reporting,
Evidence Management, etc.) and applied the Intermediate model on each,
summing the results.
Basic COCOMO Example Calculation: Effort = 2.4 × (10)^1.05 ≈ 25.2 person-months
Time = 2.5 × (25.2)^0.38 ≈ 10.1 months
People Required = Effort / Time ≈ 2.5 people
Learning Outcomes:
 Understood how to estimate project effort and duration using different COCOMO
models.
 Gained knowledge of how project attributes and team capabilities impact overall
project metrics.