E-COP
We Serve To Protect You
TEAM MEMBERS
TEAM GUIDE
Abhishek Marik
Rajdeb Saha
Suplab Debnath
Anubhab Mukherjee
Suchandra Roy
Biswajit Maji
Narula Institute of Technology
81, Nilgunj Road
Agarpara
Kolkata
DEPARTMENT OF INFORMATION TECHNOLOGY
CERTIFICATE
Date:
This is to certify that the project entitled “E-Cop” has been carried out by Abhishek Marik(IT48),
Suplab Debnath(IT35), Anubhab Mukherjee(IT54), Biswajit Maji(IT32) & Suchandra
Roy(IT26) under my guidance in partial fulfillment of the degree of Bachelor of Technology in
Information Technology of West Bengal University of Technology during the academic year 20102011. To the best of my knowledge and belief this work has not been submitted elsewhere for the
award of any other degree.
_______________________
Project Guide
____________________________
Examiner
__________________________
HOD(IT)
2|Page
Acknowledgement
We are overwhelmed in all humbleness and gratefulness to acknowledge our depth to all those
who have helped us to put these ideas, well above the level of simplicity and into something
concrete.
We like to thank to our project leader Mr. Rajdeb Saha (lecturer, Narula Institute of Technology).
He gave us moral support and guided us in different ways regarding the topic. He had been very
kind and patient while suggesting us the outlines of this project and correcting our doubts. I thank
him for his overall support.
We would also thank Narula Institute of Technology and our faculty members without whom this
project would have been a distant reality. We also extend our heartfelt thanks to our teammates
who worked for the successful completion of this project.
Abhishek Marik
Suplab Debnath
Anubhab Mukherjee
Biswajit Maji
Suchandra Roy
3|Page
Revision History
Revision Number
Date
Revision Description
Version 1
Version 2
Version 3
Version 4
Version 5
Version 6
Version 7
Version 8
Version 9
Version 10
18/08/2010
13/09/2010
10/11/2010
15/11/2010
16/11/2010
30/12/2010
18/01/2011
09/02/2011
01/04/2011
05/04/2011
Version 11
08/04/2011
Project Proposal Completed
Start SRS Document
SRS Document Completed
Minor Changes
Start Software Design Document
Screen Shots are added
Design Document Completed
Start Test Design Document
Test Design Document Completed
User Manual & Bibliography are
added
Index is added & Minor Changes
4|Page
Table of Contents
1 Project Proposal
1.1
1.2
1.3
1.4
Context of The Project
Product Overview
Feasibility Justification
Project Scenario
2 Software Requirement Specification
2.1
Introduction
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.2
Overall Description
2.2.1
2.2.2
2.2.3
2.2.4
2.2.5
2.3
Purpose
Scope
Glossary
References
Overview of Document
System Environment
Functional Requirement Specification
User Interface Specification
Non-functional Requirement Specification
System Evolution
Diagrams
2.3.1 Class Diagram
2.3.2 Entity-Relationship Diagram
2.3.3 Gantt Chart
3 Software Design Document
3.1
Introduction
3.1.1
3.1.2
3.1.3
3.1.4
3.2
Purpose
Scope
References
Overview of Document
Architectural Design
3.2.1 Deployment Diagram
3.2.2 Use Case Realization
3.2.3 Data Flow Diagrams
5|Page
3.3
User Interface Design
3.3.1 Screen shots
3.3.2 Sample Code
3.4
Database Design
4 Test Design Document
4.1
Introduction
4.1.1
4.1.2
4.1.3
4.1.4
4.1.5
4.2
Test Plan
4.2.1
4.2.2
4.2.3
4.2.4
4.3
Purpose
Scope
Glossary
References
Overview of Document
Schedules & Resources
Test Recording
Test Reporting
Static Testing
Verification Testing
4.3.1 Unit Testing
4.3.2 Module Testing
4.4
Validation Testing
4.4.1 System Testing
4.4.2 Acceptance & Beta Testing
4.5
Appendix
4.5.1 Verification Tests
4.5.2 Validation Tests
5 User Manual
5.1
Introduction
5.1.1
5.1.2
5.1.3
5.1.4
5.2
Purpose
Scope
References
Overview of Document
Installation Information
6|Page
6 Bibliography
7 Index
7|Page
Project Proposal
1.1 Context of the Project
Conventionally the citizen has to go to police station in person to make
complaints. E-cop provides a facility where citizen can make emergency
complaint and the corresponding police officer gets an immediate e-mail and
responds to it. Also the citizen can make a report missing persons, report
missing valuables and can report about wanted criminals. E-cop establish a
virtual police station setup to provide a very easy to access police service to
the citizen of Kolkata. It saves the valuable times of our citizen. Citizen can also
make request for loudspeaker, mass meeting etc. licenses from his home just
by clicking some links online.
E-cop also provides an interface where assigned police officers of each
police station of Kolkata can log in the system and perform their duties such
as complaint approvals, FIR filing, License approvals and various other form (
e.g. Arrest form, Crime Details form, Property Seizure form, Final form etc.)
creation for investigation.
1.2 Product Overview
Citizens of Kolkata often have to face a common problem in making a
complaint. To make a complaint they have to go to the police station. It is very
problematic to them when a mid-night emergency comes.
The Internet now provides a very fast access to each and every resource
throughout the world. Almost each and every educated citizen has knowledge
about the usage of the Internet. For this reason, Kolkata Police plans the make
an online police station setup for the easy access and convenience of the
citizens as well as police officers. This website is called E-cop. This website
helps citizens in great extent to make complaints, report missing person,
valuables and criminal information’s, request to approve licenses. Not only
citizens, but the employee i.e. police officers get advantages from this website.
8|Page
This makes their daily duties such as FIR filing, license approvals easier and
less error-prone.
1.3 Feasibility/Justification
The documentation of the project must be completed by the end of
April, 2011. The Gantt charts provided depict a reasonable schedule in which
the goal should be completed. The knowledge of database manipulation is
necessary for this project, so that the proper information can be accumulated
and compared to derive the necessary output. A very user friendly interface
and aesthetically pleasing design would be necessary for the user of the
system, so that they can complete this process whenever necessary,
conserving as much time as possible.
1.3 Project Scenario
Name of the
1.
Project
E-Cop
"We serve to protect"
To deliver next generation police and law enforcement reporting tools,
2.
Objective/ Vision
and setting up intelligence platforms that agencies use to take incoming
incident reports, lessen live employee resources and allow these
enforcement agencies to reallocate resources to much needed
community areas
Users of the
3.
System
A. Citizen
B. Police officers (Constable to DGP)
C. Administrator
9|Page
i. Administrator should be able to create/edit a virtual police station
(PS) which represents a real police station as a first time setup.
ii. Appointing of police officers to a particular police station which is
present in a specific zone or to a specific district as a first time setup,
he should be transferable at later time.
iii. PS should have areas of control which can be modified at later
time.
iv. When a complaint is made it undergoes various processes like FIR,
Charge Sheet, Property Seizure, court disposal etc all these activities
are performed by a PS.
v. Maintaining the criminal information state wise/area wise/age wise
Functional
Requirements
is mandatory
(At least Eight)
vii. Communication between officers is mandatory through forum,
vi. Sharing of case details with PS in other states is needed.
4.
chat, polls.
viii. The magistrate should be able to access the case details and
provide/deny the arrest warrant.
ix. Citizens should be able to apply for various licenses like loud
speaker, mass meetings etc., and the officer should be able to
approve/reject which will be notified to the applicant via and Mail.
x. Secured registration of citizens is needed where they need to
provide proof of citizenship, which will be cross checked by the police
officer of that area.
i.
Secure access of confidential data (user’s details). SSL can be
used.
requirements (At
ii.
24 X 7 availability
least Two)
iii.
Better component design to get better performance at peak time.
iv.
Flexible service based architecture will be highly desirable for
future extension.
Non-functional
5.
a. Integration of E cop with Prison management and Court is an
immediate requirement
6.
Optional features
b. Chat provides added feature
c. Biometric authentication (Face detection or Fingerprint).
d. Predicting criminal faces in various conditions using digital image
processing via face points would be additional feature
10 | P a g e
User interface
7.
priorities
A. Professional look and feel
B. Use of AJAX at least with all registration forms
C. Browser testing and support for IE, NN, Mozilla, and Firefox.
A. Complaints filed in a day and action taken to it. It should also
report unattended complaints.
B. Crime rate due to various types of crimes in a month/year and also
8.
Reports
in district/state wise.
C. Report regarding most wanted criminals and bounty information if
available.
D. Police officers often export the FIR copy to PDF format.
A. The Police station should go online, i.e., evens the Station Diary;
Station House Officer Diary should go online.
9.
Other important
B. Everything should be customizable by Administrator i.e. even the
issues
home page contents.
C. It should be start of an E-governance system, so the registered
member details may be used for various purposes
10.

PHP

HTML
Technologies to be

Javascript
used

JSON

AJAX

SQL

WAMP

Dreamweaver

Smart Draw

Microsoft Word

Linux will be the preferred OS.
11. Tools to be Used
12.
Final Deliverable
must include
A. Online or offline help to above said users
B. Database backup
C. Complete Source code
11 | P a g e
Software Requirement Specification
2.1 Introduction
2.1.1 Purpose
This Software Requirements Specification provides a complete
description of all the processes and specifications of the E-cop. The expected
audience of this document is a central administrator in charge of registration
and the software development team.
2.1.2
Scope
 Create different employees and assign corresponding privileges.
 Maintain a centralized database to provide security to information which
can be accessed only by the admin.
 Employee logs on to his account to view complaints and files FIR which
is sent by citizens.
 Creating dynamic employees like Inspector, Head constables and other
officials as the first time setup.
 Supervision of lower designation officers by higher designation officers.
This customizable feature allows admin user to create required amount
of employees.
 Transfer employee and promotion feature.
 Maintains history of the employee’s right from the date of join to his
retirement. Also the retired employee record is also maintained.
 Track all the employees, citizens and their contact details.
 All users are authenticated to avail the service.
 Confirmation link is sent to the new user and employee when signing up.
 Java client facility for working officers.
 FAQ section is also included for users benefit.
12 | P a g e
2.1.3
Glossary
 Admin – Administrator (super user), he is the controller of all the employees,
citizens and maintaining all records of the citizen and employees.
 Employees – Director General of Police, Superintendent of Police, Inspector, Sub
Inspector, Head Constable and other officials who are working in police
department.
 Citizen – End users, those who only registered in this site.
 HTML – Hypertext Markup Language is to create static websites.
 PHP – PHP: Hypertext Preprocessor is a widely used, general-purpose scripting
language that was originally designed for web development to produce dynamic
web pages. For this purpose, PHP code is embedded into the HTML source
document and interpreted by a web server with a PHP processor module, which
generates the web page document.
 MySQL– MySQL is a relational database management system (RDBMS) that runs as
a server providing multi-user access to a number of databases.
 Apache –The Apache HTTP Server, commonly referred to as Apache is web server
software notable for playing a key role in the initial growth of the World Wide Web.
 AJAX – Asynchronous Java script and XML.
2.1.4
References
 IEEE SRS Format
2.1.5 Overview of Document
The remainder of the SRS document includes the functional & nonfunctional requirements of E-cop system. It describes the environment under
which the E-cop system operates.
2.2 Overall Description
The E-cop System utilizes numerous files and information from Police
Administration Database, as well as a file on the web server system. This
system will be completely web-based, linking to database and the remote web
server from a standard web browser. An Internet connection is necessary to
access the system, and printing will be done locally, if requested.
13 | P a g e
2.2.1 System Environment
Aside from the database system, the E-cop System will rely on a remote
web server while being run from a client browser. In this section, we describe
this controlled environment. The administrator begins a generate reports
session, and a file concerning the requirements of each major in the form of a
database tree is loaded into a temporary database on the web server. The
system loads files from database when requested.
2.2.2
Functional Requirements Specification
Functional requirements are those which are provided to the users of the site,
i.e. What processes can be operated by the citizens, admin and police personnel.
Citizen
 Sign up- In order to apply for various certificates such as birth, community, income
and ration card, and end user must sign up by filling the sign up form and get it
approved by admin.
 Sign in- After getting the username and password, end users can log on to their
account and can access the website.
 Open Profile- End user can open their profile which contains the personal details
which he/she provided during sign up.
 View Profile- End user can view their profile which contains the personal details
which he/she provided during signup.
 Update Profile- End user can update their profile which contains the personal
details which he/she provided during signup.
 Request for Licenses- End user who signed in can request for various licenses such
as arms, loud speaker, mass meetings and gymnasium.
 Enter Details- End user who signed in can open the requisition form and enters the
mandatory details required in that form.
 Make an Emergency Complaint- End user can come to the portal can make an
emergency complaint directly.
 Make a Complaint- End user who signed in can complaint a crime as a complainant
or informant.
 Report Wanted Criminals- End user who signed in can report about the wanted
criminals and can collect the rewards from the government.
 Report Missing Valuables- End user who signed in can report about the missing
valuables and can collect the rewards from the government.
 Answering Polls- End user who signed in can participate in polls arranged by Ecops.
14 | P a g e
Employee
 Sign in- First the Station House Officer has to login to his account to start his work.
 Investigation- He investigates grave crimes and other complaints.
 Arresting Criminals- He arrests the criminals who are involved in the crime and
produces to the magistrate. And the arrested criminal details are added to the
criminal directory.
 Property Seizure- If the case involves property seizure; he can seize the property
and can keep in secured place.
 Maintaining Case Diary- He writes the investigation details in the case diary
including arrested criminals, property seizure, final report and appeal results of the
case.
 Adding Criminals Details- He can add the details of criminals in the criminals’
directory which is useful for the end users and also for police officers while arresting
them.
 Controlling Sub-ordinates- It is the duty of Station House Officer to supervise the
work of his subordinates like constables and head constables and he has allocate
proper work to them.
Administrator
 Verify details- Admin authenticates all the end users and officers by checking their
username and password.
 Provides login account - After getting the sign up details from the end user, Admin
provides the username and password to the end user that should be kept for future
login and also admin checks for uniqueness.
 Maintains database- Admin maintains the entire database and he is the only
authorized person to add/remove/edit employee records and end user records
provided he has to get the order from the highest designation officer.
 Add crime details- Admin adds the crime details which are given by the Station
House Officer at various times of investigation. Admin maintains the entire details of
the case including property seizure, arrest/surrender and final report.
 Adding FAQs- Admin helps to clear the doubts of citizens in this section by creating
some frequently asked questions and its corresponding answers.
 Adding Laws and Acts- Laws & acts section contains the database of the rules &
sections of Indian Penal Code (IPC) enrolled by the admin.
 Adding Polls- Polls section helps to derive conclusion to various kinds of hot topics
or issues in the arena.
15 | P a g e
2.2.3
User Interface Specification
E-cop System supports full web browser compatibility i.e. it functions in
the similar way in each well known web browser without much distortion. Ecop provides a very simple & easy to use interface so that common people
can handle this system without must complication. Administrators additionally
must be comfortable with the concept of a database.
2.2.4
Non-functional Specification
Non-functional requirements are not functional in nature, i.e. these are the
constraints of the system, within which it should function.
Hardware
Operating
System
Software
Needed
Performance
Network
Interface
2.2.5
IBM compatible, Pentium based PC with a monitor, keyboard and mouse.
Both Windows and Linux platform is supported.
A standard web browser, Apache, MySQL, PHP.
Moderate speed.
A local intranet server like Apache is required to access the website.
System Evolution

The unique user identification (UID), for every citizen, as
conceived by the Government of India, would prove to be an added
benefit and easy account verification and tracking measure.

A possible future goal would be to develop fingerprint
recognition and face recognition system. This would help administrator
as a proof of identity.

Another future goal of the system would be to develop SMS
facility.

Provision of a forum and live chat are possible future scopes.
16 | P a g e
2.3 Diagrams
2.3.1
Class Diagram
Figure: -Class Diagram
17 | P a g e
2.3.2
Entity-Relationship Diagram
Figure: -E-R Diagram
18 | P a g e
2.3.3
Gantt Chart
Figure: -Gantt Chart
19 | P a g e
Software Design Document
3.1 Introduction
3.1.1 Purpose
This Software Design Document provides details of The E-cop System.
The expected audience is designated system administrators in the Registration
Department and the software developers.
3.1.2 Scope
This Document contains a complete description of the E-cop system.
The system is based upon the server execution of a resident program. This is
the core of the system, and built around it is the ability to access the Police
Administrator Database.
Software design document contains the deployment diagram, data flow
diagrams, structure chart, user interface design with sample code, page
contents and database design.
3.1.3 References
 E-cops Software Requirement Specification Document, 2010
3.1.4 Overview of Document
The remaining chapters and their contents are listed below: Architectural Design- uses information flowing characteristics, and maps them into
the program structure. The transformation mapping method is applied to exhibit
distinct boundaries between incoming and outgoing data. The Data Flow diagrams
allocate control input, processing and output along three separate modules.
 User Interface Design- describes internal and external program interfaces, as well as
the design of human interface.
 Data Design- describes structures that reside within the software. Attributes and
relationships between data objects dictate the choice of data structures.
20 | P a g e
3.2 Architectural Design
3.2.1 Deployment Diagram
Deployment Diagram shows the physical locations where the system actually exists.
This allows a clear explanation of where each design entity will reside. Each part will work in
unison to accomplish each requested task.
Figure: -Deployment Diagram
E-cops Database is external to the system.
The Web server contains the modules or files needed for your system.
A browser on the client side is used to communicate with the browser.
3.2.2 Use Case Realization
Actors: Citizen: - Citizens are those who take the services provided by E-cop. These
are the common inhabitants of the city. The main function of citizens in this
system are: o Sign up
o Sign in
o Requests for licenses
o Making complaints
o Report Missing Person
o Report Missing Valuables
o Check passport status
o Answering Polls
 Employees: - Employees are those who work under E-cops. The main
function of employees in this system are: 21 | P a g e
o Sign in
o Add/Manage Criminals Records
o File FIR
o Approve Citizen Signups
o Approve Licenses
o Manage Crime Details, Arrest, Property Seizure and Final Forms
o Uploads files (e.g. Fingerprints, documents, pictures etc.)
 Administrator: - Administrators are those persons who manage the whole
Citizen and Employee information of E-cop. The main function of
Administrator in this system are: o Sign in
o Maintain Database
o Add/Manage Police Stations
o Add/Manage Police Officers
o Manages Rejected Complaints
o Maintains Crime Details
o Add/Manage FAQs
o Add/Manage Help & Support
o Add/Manage Polls
Use Cases:


















Citizen Signup
Citizen Login
Make an Emergency Complaint
Make an Non-emergency Complaint
Checking Passport Status
Report Missing Person
Report Missing Valuables
Request Licenses
Answering Polls
View Laws/Acts
View Help & Supports
Report Wanted Criminals
Approve Complaints
Approve Licenses
File FIRs
Final Forms
Adding Criminal Details
Crime Details
Arrest Forms
22 | P a g e







Property Seizure Forms
Maintains Database
Add Police Officers
Add Police Stations
Add/Manage Polls
Add/Manage Laws/Acts
Add/Manage Help & Supports
Use Case Diagram:-
Figure: -Use Case Diagram
23 | P a g e
Use Cases: Citizen Use Cases ---Citizen Signup :Use Case Name: Citizen Signup
ID: CSU
Primary Actors: Citizen, End Users
Brief Description:
This use case describes creation of citizens’ profile in the E-cop database
system.
Goal:
 Successful creation of users account
Success Measurement:
 Message will be shown displaying `your request has been accepted`.
Preconditions:
 User should meet the terms and conditions
 User id should be unique
 All the mandatory fields should be filled up
Trigger:
 When citizen wants to create an account
Typical flow of Events:
 User first logs on to the E-cops website through the Internet
 In the service page he will click on `Register for an account` link
 User should fill all the necessary fields appropriately
 After that User must click on submit button to submit his registration
form
 The form will go to assigned police officers for verification and
approval
Assumptions:
 It is assumed that user will enter all meaning full data
 It is assumed that workflows will be carried out internally
 Citizen Use Cases ---Citizen Login :Use Case Name: Citizen Login
ID: CLI
Primary Actors: Citizen, End Users
Brief Description:
This use case describes successful log in by the user
Goal:
 Successful log in by the user
 Create session for logged in user
24 | P a g e
Success Measurement:
 Message will be shown displaying `Welcome username` and the user
will be redirected to services page.
Preconditions:
 User id and password, both should match
 That user must be approved by station house officer
 User must submit registration form before log in
Triggers:
 When citizen wants to log in
Typical flow of Events:
 User first logs on to the E-cops website through the Internet
 In the service page he has to fill the E-mail ID/User ID and password
fields
 If log in is successful user will redirected to `services` page
 Otherwise message will be shown for unsuccessful log in
Assumptions:
 Citizen Use Cases --- Make an Emergency Complaint :Use Case Name: Make an Emergency
ID: MEC
Complaint
Primary Actors: Citizen, End Users
Brief Description:
This use case describes creation of unapproved emergency complaint by
user.
Goal:
 Successful creation of unapproved emergency complaint
Success Measurement:
 Message will be shown displaying `yours complaint has been filed `
and your complaint no.
Preconditions:
 User may or may not be logged in
 Mandatory fields are filled
Trigger:
 When citizen wants to make an emergency complaint
Typical flow of Events:
 User first logs on to the E-cops website through the Internet
 Click on the Emergency Complaint link in the home page
 User should fill all the necessary fields appropriately
25 | P a g e
After that User must click on submit button to submit his complaint
The form will go to assigned police officers for verification and
approval
Assumptions:
 It is assumed that user will enter all meaning full data
 It is assumed that workflows will be carried out internally


 Citizen Use Cases --- Report Missing Person :Use Case Name: Report Missing Person ID: RMP
Primary Actors: Citizen, End Users
Brief Description:
This use case describes how an user can report about missing person
Goal:
 Successful creation of unapproved missing person complaint
Success Measurement:
 Message will be shown displaying `yours complaint has been filed `
and your complaint no.
Preconditions:
 User must be logged in
 Mandatory fields are filled
Trigger:
 When citizen wants to report a missing person
Typical flow of Events:
 User first logs on to the E-cops website through the Internet
 User logs in with user id and password
 Select Missing Person link
 Fill the necessary fields
 Submit the form
 The form will go to assigned police officers for verification and
approval
Assumptions:
 It is assumed that user will enter all meaning full data
 It is assumed that workflows will be carried out internally
 Citizen Use Cases --- Request Licenses :Use Case Name: Request Licenses
Primary Actors: Citizen, End Users
ID: RLS
26 | P a g e
Brief Description:
This use case describes how an user can request for licenses.
Goal:
 Successful creation of unapproved license request
Success Measurement:
 Message will be shown displaying `yours license request has been filed
` and your request no.
Preconditions:
 User must be logged in
 Mandatory fields are filled
Trigger:
 When citizen wants to request for licenses
Typical flow of Events:
 User first logs on to the E-cops website through the Internet
 User logs in with user id and password
 Select License Request link
 Fill the necessary fields
 Submit the form
 The form will go to assigned police officers for verification and
approval
Assumptions:
 It is assumed that user will enter all meaning full data
 It is assumed that workflows will be carried out internally
 Citizen Use Cases --- Approve Complaints :Use Case Name: Approve Complaints
ID: ACOM
Primary Actors: Employees, Station House Officer, Police Officer, DGP
Brief Description:
This use case describes how employees can approve complaints.
Goal:
 Successful creation of approved complaints
Success Measurement:
 Message will be shown displaying `complaint is approved ` and
complaint no.
Preconditions:
 Complaints filed by users already exits
Trigger:
 When Employee wants to approve complaints
27 | P a g e
Typical flow of Events:
 Employee first logs on to the E-cops website through the Internet
 Employee logs in with user id and password
 Select Complaints link
 Click on approve link to approve complaint
Assumptions:
 It is assumed that workflows will be carried out internally
 Citizen Use Cases --- Approve Licenses :Use Case Name: Approve Licenses
ID: ALCS
Primary Actors: Employees, Station House Officer, Police Officer, DGP
Brief Description:
This use case describes how employees can approve licenses.
Goal:
 Successful creation of approved licenses
Success Measurement:
 Message will be shown displaying `license is approved ` and license
request no.
Preconditions:
 Licenses requested by users already exits
Trigger:
 When Employee wants to approve complaints
Typical flow of Events:
 Employee first logs on to the E-cops website through the Internet
 Employee logs in with user id and password
 Select Licenses link
 Click on approve link to approve license
Assumptions:
 It is assumed that workflows will be carried out internally
 Citizen Use Cases --- Adding Criminal Details :Use Case Name: Adding Criminal
ID: ACD
Details
Primary Actors: Employees, Station House Officer, Police Officer, DGP
Brief Description:
This use case describes how employees can add criminal records.
Goal:
28 | P a g e
 Successful addition of criminal records
Success Measurement:
 Message will be shown displaying `criminal record added successfully`
Preconditions:
 Employee must be logged in
 Employee must have necessary permission
Trigger:
 When Employee wants to add criminal details
Typical flow of Events:
 Employee first logs on to the E-cops website through the Internet
 Employee logs in with user id and password
 Select Criminals link
 Fill mandatory fields
 Click Submit Button
Assumptions:
 It is assumed that workflows will be carried out internally
 Citizen Use Cases --- Adding Police Officers :Use Case Name: Adding Police Officers ID: APO
Primary Actors: Administrator
Brief Description:
This use case describes how admin can add police officers.
Goal:
 Successful addition of police officers
Success Measurement:
 Message will be shown displaying `police officer added successfully`
Preconditions:
 Admin must be logged in
Trigger:
 When Admin wants to add police officers
Typical flow of Events:
 Admin first logs on to the E-cops website through the Internet
 Admin logs in with user id and password
 Select Police Officers link
 Fill mandatory fields
 Click Submit Button
Assumptions:
 It is assumed that workflows will be carried out internally
29 | P a g e
 Citizen Use Cases --- Adding Police Stations :Use Case Name: Adding Police
ID: APO
Stations
Primary Actors: Administrator
Brief Description:
This use case describes how admin can add police stations.
Goal:
 Successful addition of police stations
Success Measurement:
 Message will be shown displaying `police station added successfully`
Preconditions:
 Admin must be logged in
Trigger:
 When Admin wants to add police stations
Typical flow of Events:
 Admin first logs on to the E-cops website through the Internet
 Admin logs in with user id and password
 Select Police Station link
 Fill mandatory fields
 Click Submit Button
Assumptions:
 It is assumed that workflows will be carried out internally
30 | P a g e
3.2.3 Data Flow Diagrams
Context Level DFD
It shows the interaction between the system and external agents which act as data
sources and data sinks. On the context diagram (also known as the 'Level 0 DFD') the system's
interactions with the outside world are modeled purely in terms of data flows across the system
boundary. The context diagram shows the entire system as a single process, and gives no clues
as to its internal organization.
Figure: -Context Level DFD
31 | P a g e
Level 1 DFD
This context-level DFD is next "exploded", to produce a Level 1 DFD that shows some of the
detail of the system being modeled. The Level 1 DFD shows how the system is divided into
sub-systems (processes), each of which deals with one or more of the data flows to or from an
external agent, and which together provide all of the functionality of the system as a whole. It
also identifies internal data stores that must be present in order for the system to do its job,
and shows the flow of data between the various parts of the system.
Figure: -Level 1 DFD
32 | P a g e
Level 2 DFD
 Name: - Login System
Operations: Operation Name:
Return Value:
Registration
None
Pre- Conditions:
 User should meet the terms and conditions
 User id should be unique
 All the mandatory fields should be filled up
Post-conditions:
 None
Exception:
 None
Operation Name:
Return Value:
Verification
Valid or Invalid Values
Pre- Conditions:
 User id and password, both should match
 That user must be approved by station house officer
 User must submit registration form before log in
Post-conditions:
 User is logged in to the web server
Exception:
 If successful, User is logged in. If unsuccessful, User is returned to login
screen.
33 | P a g e
 Name: - Complaint Filing and License application System
Operations: Operation Name:
Return Value:
License Application System
License Application Number
Pre- Conditions:
 User must be logged in
 Mandatory fields are filled
Post-conditions:
 License Application form will be submitted
Exception:
 None
Operation Name:
Return Value:
License Approval System
Approved License Number
Pre- Conditions:
 Employee must be logged in
 Employee must have required permission
Post-conditions:
 License will be shown in the approved licenses list
Exception:
 None
34 | P a g e
Operation Name:
Complaint Filing System
Pre- Conditions:
 User must be logged in
 Mandatory field are filled
Post-conditions:
 None
Exception:
 None
Return Value:
Complaint Number
Operation Name:
Return Value:
Complaint Approval System
Approved Complaint Number
Pre- Conditions:
 Employee must be logged in
 Employee must have required permission
Post-conditions:
 Complaint will be shown in the approved complaints list
Exception:
 None
 Name: - FIR and Court Disposals System
35 | P a g e
Operations: Operation Name:
Return Value:
FIR Filing System
FIR Number
Pre- Conditions:
 Employee must be logged in
 Employee must have required permission
 Complaint must be already approved
Post-conditions:
 FIR Number will generate
Exception:
 If the employee has not required permission FIR cannot be filed
Operation Name:
Return Value:
Court Disposal System
None
Pre- Conditions:
 Employee must be logged in
 Employee must have required permission
 FIR must be already filed
Post-conditions:
 You can see Crime Details, Property Seizure, Arrest and Final Forms
Exception:
 None
 Name: - Reporting System
36 | P a g e
Operations: Operation Name:
Valuables Report
Pre- Conditions:
 User must be logged in
Post-conditions:
 Report Number will generate
Exception:
 None
Return Value:
Report Number
Operation Name:
Missing Person Report
Pre- Conditions:
 User must be logged in
Post-conditions:
 Report Number will generate
Exception:
 None
Return Value:
Report Number
Operation Name:
Return Value:
Criminal Report System
None
Pre- Conditions:
 Employee must be logged in
 Employee must have required permission
Post-conditions:
 Criminal records are added
Exception:
 None
37 | P a g e
 Name: - Maintaining Database
Operations: Operation Name:
Return Value:
Database Insertion System
None
Pre- Conditions:
 Admin must be logged in
 Admin must have required permission
Post-conditions:
 Police station, Police Officers are added to the database
Exception:
Operation Name:
Return Value:
Database Modification System
None
Pre- Conditions:
 Admin must be logged in
 Admin must have required permission
Post-conditions:
 Police station, Police Officers are modified/deleted
Exception:
38 | P a g e
3.3 User Interface Design
User Interface will consist of many familiar looking web pages. Citizen, Employee and
Administrator have pages of different designs. We are not going to show each and every
page in the interface design. First we will show some important screen shots and then a
sample coding.
3.3.1 Screen Shots
 Citizen Section
Figure: -Citizen Login Form
Figure: -Citizen Services Page
39 | P a g e
Figure: -Citizen Signup Form
Figure: -Emergency Complaint Form
40 | P a g e
 Employee Section
Figure: -Employee Control Panel Page
Figure: -Approved Complaints Page
41 | P a g e
Figure: -FIR Details
Figure: -Criminal Details
42 | P a g e
 Admin Section
Figure: -Administration Control Panel
Figure: -Add Police Officer
43 | P a g e
Figure: -View Police Station
Figure: -Logout Confirm
44 | P a g e
3.3.2 Sample Code
<?php
// Database Constants
define("DB_SERVER", "localhost");
define("DB_USER", "root");
define("DB_PASS", "");
define("DB_NAME", "dbcop");
// Create a database connection
$con = mysql_connect(DB_SERVER,DB_USER,DB_PASS);
if (!$con) {
die("Database connection failed: " . mysql_error());
}
// Select a database to use
$db_select = mysql_select_db(DB_NAME,$con);
if (!$db_select) {
die("Database selection failed: " . mysql_error());
}
?>
45 | P a g e
3.4 Data Design
46 | P a g e
47 | P a g e
48 | P a g e
49 | P a g e
50 | P a g e
Test Design Document
4.1 Introduction
4.1.1 Purpose
This test approach document describes the appropriate strategies,
process, workflows and methodologies used to plan, organize, execute and
manage testing of E-cop system.
4.1.2 Scope
This document will address the following QA topics:
 Static testing and code documentation standards.
 Verification testing at the various levels: unit, module, and system. All
testing components will be named and referred to consistently
throughout the document.
 Validation testing including use-case realizations. We will also address
acceptance testing and beta release testing.
4.1.3 Glossary
 Test Plan: a management planning document that shows:
o How the testing will be done (including SUT (system under test)
configurations).
o Who will do it
o What will be tested
o How long it will take (although this may vary, depending upon
resource availability).
o What the test coverage will be, i.e. what quality level is required
 Test Design Specification: detailing test conditions and the expected results as
well as test pass criteria.
 Test Case Specification: specifying the test data for use in running the test
conditions identified in the Test Design Specification
 Test Procedure Specification: detailing how to run each test, including any setup preconditions and the steps that need to be followed
51 | P a g e
 Test Item Transmittal Report: reporting on when tested software components
have progressed from one stage of testing to the next
 Test Log: recording which tests cases were run, who ran them, in what order, and
whether each test passed or failed
 Test Incident Report: detailing, for any test that failed, the actual versus
expected result, and other information intended to throw light on why a test has
failed.
 Test Summary Report: A management report providing any important
information uncovered by the tests accomplished, and including assessments of
the quality of the testing effort, the quality of the software system under test, and
statistics derived from Incident Reports.
4.1.4 References
 E-cops Software Requirement Specification Document, 2010
 E-cops Software Design Document, 2010
 IEEE 829-2008 Specification
4.1.5 Overview of Document
This document has three additional chapters of interest. The next
chapter discusses the test plan, that is, how testing will be done and how
results will be recorded and reported. The chapter following describes
verification testing, that is, testing of individual components of all sizes to
ensure that they meet the requirements stated in the SRS. The final chapter
describes validation testing, that is, testing of the functionalities of the system
against the needs of the user as specified in the SRS. Acceptance testing and
Beta release testing are also covered in this chapter.
4.2 Test Plan
4.2.1 Schedules & Resources
The specified software developers will test each individual component
for basic functionality as each is constructed. When a major code component
is completed to their design specifications, it will be turned over to a
designated testing team for comprehensive testing. Developers will have no
52 | P a g e
need to formally test their own work, as the testing team will provide a more
objective approach. This includes all the code modules. At the end of each
development iteration, all use-case realizations that are thought to be
complete will be tested for functionality.
The testing team will record all errors encountered, and the software
development team will be notified. After correction, the cycle will repeat itself,
with every test being rerun. Upon project completion, the entire system will
be subjected to a trial run with real data from the University, comparing these
results to those created by a human projection using the same data. These
comparison results will be inadequate, as there is too much information
contained within these files to be accessed in a reasonable amount of time by
hand, but will provide a rough guideline for evaluation.
Once delivered to the client, the software team will monitor use, and be
prepared to correct any errors or make any additions that are required.
4.2.2 Test Recording
Test recording will use the form designated by Figure, and described
below.
 Test Item refers to the name of the code module or use case as listed
and detailed in the next two chapters.
 Developer refers to the person responsible for the software
development of this unit and to whom problems need to be
communicated.
 Tester refers to the principle tester of the component, if more than one
person tests a unit. The principle tester is responsible for maintaining
this record.
 Test Specification refers to the name of the section in the Appendix
that includes the testing process, test data and the expected results. It
also lists the other components that are linked to this Test Item, and
must be retested whenever this component is retested because of
change (regression data). Finally, it lists the cross-reference to the SDD
where it is described and the code where it is implemented.
53 | P a g e
 Date Tested refers to the date at which the testing is completed and this
record updated.
 Result is designated either Pass or Fail. If a test is failed, specific details
surrounding the failure will be given in written form to the developer for
correction.
Test Item*
Developer
Tester
Name
Test
Specification
Date Tested
Result
Figure: - Testing Record Form
* Here we use ‘ModuleID.SubmoduleID.UnitID.TestCaseID’ format for Test Item
4.2.3 Test Reporting
A master list of all testing and the results will be maintained using the
form listed below. This will be kept in electronic form and updated as each test
is performed. Note that this is a summary of the Testing Record Form and
must be used in conjunction with that form.
 Test Item refers to the name of the component/use case as listed in the
next two sections. All names will be preprinted on this form.
 Status includes Untested, Passed, Failed, and Needs Retested. The term
Needs Retested refers to an item, which has previously passed, but now
needs to be retested because a related item has been retested
(regression testing).
 For Date Scheduled/Tested, Tested should record only passed tests. All
others should be Scheduled.
Test Item
Status
Date Scheduled/Tested
Figure-Test Summary Report
54 | P a g e
4.2.4 Static Testing
Each unit of code will be fully documented with the documentation
found in the detailed design of the Software Design Document. After each
code component is coded and before the designated team dynamically tests
it, it shall be provided to the team as a whole excluding the developer to
identify errors or omissions. If problems are found, the code will be returned
to the developer with the problem(s) identified. After correction is done, the
code will again be reviewed.
4.3 Verification Testing
4.3.1 Unit Testing
The following units must be tested. The test specifications are contained
in the Appendix to this document. For convenience, units are grouped by
enclosing module.
Module Name( Module ID )
Citizen login(04)
Complaint Report(05)
License Application(06)
Approvals(07)
Criminals(08)
Unit Name( Unit ID)
Citizen Registration (01)
Citizen Sign in(02)
Emergency Complaint Report(01)
Non-emergency Complaint Report(02)
Missing person report(03)
Missing valuables report(04)
License Application(01)
Citizen Signup Approval (01)
License Approval(02)
Complaint Approval(03)
Add Criminals(01)
View Criminals(02)
Edit Criminals(03)
Delete Criminals(04)
55 | P a g e
FIR(09)
Police Station(10)
Police Officer(11)
Laws and Acts(12)
Polls(13)
Help and Support(14)
FIR filing(01)
View FIR(02)
Crime Details(03)
Arrest/Surrender(04)
Property Seizure (05)
Final form(06)
Add Police Station (01)
Delete Police Station(02)
View/Modify Police Station(03)
Add Police Officer (01)
Delete Police Officer(02)
View/Modify Police Officer(03)
Add Laws and acts(01)
Delete Laws and acts(02)
Modify Laws and acts(03)
Add Polls(01)
Delete Polls(02)
Modify Polls(03)
Add Help Info(01)
Delete Help Info(02)
Modify Help Info(03)
4.3.2 Module Testing
The following modules must be tested. The test specifications are
contained in the Appendix to this document. Formal module testing will be
done only after all units in that module are tested. To allow testing incomplete
modules, we treat an incomplete module as a complete module with a
different name. The module that it is part of is referenced here. The complete
module has None in its Part of column.
Module Name( Module ID )
Citizen (01)
Part of
None
56 | P a g e
Employee(02)
Administrator (03)
Citizen Login(04)
Complaint Report(05)
License Application(06)
Approvals(07)
Criminals(08)
FIR(09)
Police Station(10)
Police Officer(11)
Laws and Acts(12)
Polls(13)
Help and Support(14)
None
None
Citizen (01)
Citizen (01)
Citizen (01)
Employee(02)
Employee(02)
Employee(02)
Administrator(03)
Administrator(03)
Administrator(03)
Administrator(03)
Administrator(03)
4.4 Validation Testing
4.4.1 System Testing
All use cases must be tested. Use cases must work in combination with
other use cases. In order to test these cases we must run the system under
different conditions and sequences.
4.4.2 Acceptance & Beta Testing
After the above Testing has been performed, it is important to check
that the system will work under real data. The system will be run for testing
using last year’s data.
57 | P a g e
4.5 Appendix
4.5.1 Verification Tests
 Unit name:- Citizen Sign in
Test cases:Test case(Test case ID)
No Input or one of the input is missing (01)
E-mail id or password or both are not matched
(02)
Both are matched (03)
Result Expected
‘Enter a valid email id’ and ‘enter
password’ message will be shown
‘Email-id and password do not match!!!’
will be shown
Redirect to the services page and create
session
Test Record:Test Item
01.04.02.01
01.04.02.02
01.04.02.03
Developer
Suplab Debnath
Suplab Debnath
Suplab Debnath
Tester Name
Abhishek Marik
Abhishek Marik
Abhishek Marik
Date Tested
27/03/2011
27/03/2011
27/03/2011
Result
passed
passed
passed
 Unit name:- Non-emergency Complaint Report
Test cases:Test case(Test case ID)
No Input or atleast one of the necessary inputs is
missing(01)
All mandatory fields are entered (02)
Result Expected
Message will be shown requesting to
enter the mandatory fields
Data will be entered into the `complaint`
table and `successful complaint
submission` message will be shown
Test Record:Test Item
01.04.02.01
01.05.02.02
Developer
Suplab Debnath
Suplab Debnath
Tester Name
Abhishek Marik
Abhishek Marik
Date Tested
27/03/2011
27/03/2011
Result
passed
passed
58 | P a g e
 Unit name:- Crime Details
Test cases:Test case(Test case ID)
FIR is not prepared(01)
FIR is prepared,but crime details information is
not entered(02)
Necessary fields are empty(03)
All the entries in the crime details form are correct
(04)
FIR is prepared and crime details form is also
prepared(05)
Result Expected
Crime details cannot be inserted
Crime details can be inserted
Message will be shown to enter the
fields
Data will be written to the `crimedetails`
table
Only show the crime details information
in read only format
Test Record:Test Item
02.09.03.01
02.09.03.02
02.09.03.03
02.09.03.04
02.09.03.05
Developer
Abhishek Marik
Abhishek Marik
Abhishek Marik
Abhishek Marik
Abhishek Marik
Tester Name
Suplab Debnath
Suplab Debnath
Suplab Debnath
Suplab Debnath
Suplab Debnath
Date Tested
28/03/2011
28/03/2011
28/03/2011
28/03/2011
28/03/2011
Result
passed
passed
passed
passed
passed
 Unit name:- Add Criminals
Test cases:Test case(Test case ID)
Necessary fields are empty(01)
All the entries are correct (02)
Result Expected
Message will be shown to enter the
fields
Data will be written to the `criminals`
table and redirect to `addcriminal` page
Test Record:Test Item
02.08.01.01
02.08.01.02
Developer
Anubhab Mukherjee
Anubhab Mukherjee
Tester Name
Suplab Debnath
Suplab Debnath
Date Tested
28/03/2011
28/03/2011
Result
passed
passed
59 | P a g e
 Unit name:- Add Police Officer
Test cases:Test case(Test case ID)
Necessary fields are empty(01)
All the entries are correct (02)
Result Expected
Message will be shown to enter the
fields
Data will be written to the `criminals`
table and redirect to `addcriminal` page
Test Record:Test Item
03.11.01.01
03.11.01.02
Developer
Biswajit Maji
Biswajit Maji
Tester Name
Suchandra Roy
Suchandra Roy
Date Tested
28/03/2011
28/03/2011
Result
passed
passed
 Unit name:- Add Police Station
Test cases:Test case(Test case ID)
Necessary fields are empty(01)
All the entries are correct (02)
Result Expected
Message will be shown to enter the
fields
Data will be written to the `criminals`
table and redirect to `addcriminal` page
Test Record:Test Item
03.10.01.01
03.10.01.02
Developer
Suchandra Roy
Suchandra Roy
Tester Name
Biswajit Maji
Biswajit Maji
Date Tested
28/03/2011
28/03/2011
Result
passed
passed
60 | P a g e
4.5.2 Validation Tests
Cross-Platform Browser Compatibility Testing:-
Linux
Crome 10.0
Crome 11.0
Crome 6.0
Crome 9.0
Dilo 2.2
Elinks 0.13
Epiphany 2.30
Firefox 3.6
Firefox 3.5
Flock 2.6
Galeon 2.0
Iceape 1.1
Iceweasel 3.0
Kazehakase 0.5
Konqueror 3.5
Konqueror 4.5
Konqueror 4.6
Lynx 2.0
Minefield 3.7
Navigator 9.0
Opera 10.0
Opera 11.0
Opera 9.80
Safari 533.3
SeaMonkey 2.0
Shiretoko 3.5
Windows
passed
passed
failed
passed
failed
failed
passed
passed
passed
failed
passed
failed
failed
passed
failed
passed
passed
failed
passed
passed
passed
passed
passed
failed
passed
failed
Avant 11.7
Crome 10.0
Crome 9.0
Firefox 1.5
Firefox 2.0
Firefox 3.6
Firefox 4.0
Flock 2.6
Flock 7.0
K-meleon 1.5
MSIE 6.0
MSIE 7.0
MSIE 8.0
Minefield 3.7
Opera 8.54
Opera 9.80
Safari 4.0
Safari 5.0
SeaMonkey 1.1
SeaMonkey 2.0
passed
passed
passed
failed
failed
passed
passed
passed
failed
passed
passed
passed
passed
passed
passed
passed
failed
passed
failed
passed
61 | P a g e
Browser Screen Shots:-
Firefox 4.0
Opera 8.54
62 | P a g e
Netscape 8.1.3
Lynx 2.8.7
63 | P a g e
User Manual
5.1 Introduction
5.1.1 Purpose
This document will provide guidance for users of the E-cop System.
5.1.2 Scope
This Document addresses the installation procedure of E-cop system.
5.1.3 References
 E-cops Software Requirement Specification Document, 2010
 E-cops Software Design Document, 2010
5.1.4 Overview of Document
These chapters walk a user through normally encountered system
usages, providing examples and screenshots for ease of use.
5.2 Installation Information
 Installation in Local host
Enter the CD which is provided for installing the E-cop system.
Open the WAMP Server Folder
Install WAMP Server in the C Drive of your computer.
After Installing, run the WAMP Server from Start menu or for the
Desktop Shortcut.
o Go to C Drive  wamp  www.
o Copy E-cop Folder from CD to that location.
o Open your web browser and type http://localhost/phpmyadmin/ in
the URL and press ENTER.
o
o
o
o
64 | P a g e
o
o
o
o
Create a database named ‘dbcop’.
Then import the dbcop.sql file from Database folder.
Again type http://localhost/E-cop/ in the URL and press ENTER.
Installation procedure is complete. Now you can enjoy E-cop
system.
N.B:- When you are operating E-cop system in local host e-mail facilities will not be
available until SMTP is properly configured.
65 | P a g e
Bibliography
 http://php.net
 (O`Reilly) Programming PHP (2nd Edition)
 (O'Reilly) PHP (Cookbook)
 (O'Reilly) PHP (Pocket Reference, 2nd Edition)
 (O'Reilly) MySQL (Cookbook)
 (O'Reilly)Head First PHP
 (O'Reilly)Head First AJAX
 Laika Design Document
 IEEE Project Report Format
 IEEE Test Design Specification
 Wikipedia
66 | P a g e
Index
A
D
Acceptance 58
Data Design 47
Acknowledgment 3
Data Flow Diagram 32
Actors 22
Admin 14, 44
Administrator 16, 23, 57
Deployment Diagram 22
Design Document 21, 52
AJAX 14
Developer 54
Apache 14
Diagram, SRS 18
Appendix 59
E
Architectural Design 21, 22
Area 46
E-cop 2, 8, 9, 13, 14, 15,
Arrest form 46
Employee 14, 16, 22, 42,
Assumptions 25, 26, 27, 28, 29, 30, 31
Attachments 46
B
Beta Testing 58
E-R Diagram 19
F
Feasibility 9
Bibliography 67
Functional Requirements 10, 15
Browser Compatibility Testing 62
G
Browser Screen Shots 62, 63
C
Certificate 2
Citizen 14, 15, 22, 40
Gantt chart 19
Glossary 14, 52
H
Class Diagram 18
HTML 14
Code Sample 46
L
Context level DFD 32
Context of the Project 7
Level 1 DFD 33
Level 2 DFD 34
67 | P a g e
Linux 62
Scope 13, 21, 52, 65
Local host 65
Screen shots 39
M
SRS 13
Module Testing 57
MySQL 14
N
Non-functional Requirements 10, 17
O
Optional Features 11
Overall Description 14
Overview 14, 21, 53
P
PHP 11, 14
Product Overview 8
Purpose 13, 21, 52, 65
R
Static Testing 56
System Environment 15
System Evolution 17
System Testing 58
T
Technologies 11
Test Case Specification 52
Test Design Document 52
Test Design Specification 52
Test Incident Report 53
Test Item Transmittal Report 53
Test Log 53
Test Plan 52, 53
Test Procedure Specification 52
Test Recording 54
References 14, 21, 53, 65
Test Reporting 55
Reports 11
Test Specification 54
Resources 53
Test Summary Report 53
Revision History 4
Tester 54
S
Tools to be used 11, 12
Scenario 9
Schedules 53
68 | P a g e
U
Validation Testing 58, 62
Verification Testing 56, 59
Unit Testing 56
Use Case Diagram 24
Use case Realization 22
W
Use cases 23, 25
WAMP 65
V
Windows 62
User Interface Design 21, 40
User Interface Specification 16
69 | P a g e