PRISON MANAGEMENT SYSTEM

1. General Description:

1.1 Purpose

This project is aimed at developing a prison management system that is a collection of

registers and reports for the effective management of prisons. This system should contain the
modules like nominal roll, case register, parole register, Interview requests, In-out register
and an automated release diary generator.
1. Nominal Roll: The details of the prisoner and his/her demographic details should be
captured. A digital photo comprising different views of the prisoner and the list of articles
surrendered by prisoner during nominal roll are to be recorded.
2. Case register: All the details of the cases against the prisoner should be captured. This must
include the sentence details, remand/conviction details, etc.
3. Automated release diary generator: This report should be display the list of prisoners to
be released on a day, the next day, the next week, the next month, or any given duration of
time. The system should consider the reduction of sentence length due to various
considerations.
4. Parole register: This module should track all prisoners on parole and provide necessary
reports on this data.
5. Interview requests and In-out register: All interview requests by the relatives of the
prisoners need to be recorded and tracked. An in-out register will track all prisoners and
others who move in and out for various reasons. This should include provisions for recording
the prisoners sent to courts for hearing.
6. Various status reports and demographical analysis reports are to be generated.

1.2 Scope

1. The system should have a login.

2. System should support for Interview requests and In-out register modules for visitors.
3. System should support for Data Entry module for Nominal Roll, Case register for each
prisoner entering in the prison.
4. Automated release diary generator
5. Jailer should be able to generate various reports Prisoner wise, case-wise.
6. Jailer should be able to generate Visitor reports Prisoner wise and Visitor wise.

1.3 Keyword Used

Generic Technology keywords:

1. Operating System
2. Databases
3. Programming
4. Software Engineering
1.4 Abbreviation Used

# HTML: Hypertext Markup Language is a markup language used to design static web pages.

#J2EE: Java 2 Enterprise Edition is a programming platform— part of the Java Platform for
developing and running distributed multi-tier architecture Java applications, based largely on
modular software components running on an application server.

#GUI: Graphical User interface with the system with mouse control and other easy to use
control features like the menus etc.

#SRS: A SRS is basically an organization’s understanding (in writing) of a customer or

potential client’s system requirements and dependencies at a particular point of time (usually)
prior to any actual design or development work. It’s a two-way insurance policy that assures that
both the client and the organization understand each other’s requirements from every perspective
at a given point of time.

#Eclipse/Net Beans: Development tool (IDE) for Web applications.

#JSP: Java server page is a standard part of the J2EE .It is used to create dynamic web pages.

#Servest: These are small programs which execute on the server side and dynamically extend
the functionality of the web browser .It generally acts as a control in the server side.

#HTTP: Hypertext Transfer Protocol is a transaction oriented client/server protocol between

web browser & a Web Server.

#HTTPS: Secure Hypertext Transfer Protocol is a HTTP over SSL (secure socket layer).

#TCP/IP: Transmission Control Protocol/Internet Protocol, the suite of communication

protocols used to connect hosts on the Internet. TCP/IP uses several protocols, the two main ones
being TCP and IP.

2. Information Description:

2.1 Product Perspective

The web pages (XHTML/JSP) are present to provide the user interface on customer client
side. Communication between customer and server is provided through HTTP/HTTPS
protocols.
The Client Software is to provide the user interface on system user client side and for this
TCP/IP protocols are used.
On the server side web server is for EJB and database server is for storing the
information.
2.2 Product Features

The system will allow access only to authorized users including administrators
and coordinators depending on the role. Following are some of the functions performed
by the software:
1. login facility for only the authorized users.
2. Provide information details to organize resources management and utilities.
3. provides security and authentication.
4. provide confirmation of successful registration.
5. Allow only administrator to perform modification such as adding or deleting the
informations or the required changes.
6. The designed product will be secure enough to use and reliable too.

2.3 User Classes And Characteristics

1. Jailor (ADMIN) :
 Login to system.
 Authorized access to database.
 Update information content.
 Create, modify and delete the data details.
 Generate updated reports.
2. Visitor :
 Registration for new accounts.
 Login to accounts through registration ID and Password.
 Update information status on account.
 Access performance details.
 Submit the reports.

2.4 Assumptions And Dependencies

This software should work even at when the workload on this software get increases.
Server should have a power backup as well as a database backup.

3. Specific Requirements
3.1 External Interface requirement

1. User Interfaces :
 2. Hardware Interfaces:
CLIENT SIDE
PROCEESOR RAM DISK SPACE
Internet Explorer CORE DUO AT 512 MB 80 GB
6.0 or above 1.6GHZ
SERVER SIDE
Apache Tomcat Pentium III at 1 512 MB 4 GB
7.0.2 GHz
MySQL 5.1.5 Pentium III at 1 512 MB 2 GB
GHz

3. Software Requirement :

 Client on Internet: Web Browser, Operating System (any)

 Client on Intranet: Client Software, Web Browser, Operating System (any)
 Web Server: Apache Tomcat, Operating System (any)
 Data Base Server: MySQL, Operating System (any)
 Development End: NetBeans (J2EE, Java, Java Bean, Servlets, HTML),
Database server (MySQL), OS (Windows XP professional), Apache Tomcat
(Web Server).

4. Communication Protocol:

 Client on Internet will be using HTTP/HTTPS protocol.

 Client on Intranet will be using TCP/IP protocol.

4. Users of the system: 1. Jailor (ADMIN)

2. Visitor

5. Functional Components:
 1. Nominal Roll
2. Case Registers
3. Interview requests
4. In-out register
5. Reports and release diary

6. DATABASE FIELD SPECIFICATION:

LOGIN TABLE
N0. Field name Type of field Remarks
1. Username Varchar2(15) Primary key
2. Password Number(10)

NOMINAL ROLL REGISTER

No. Field Name Type of variable Remarks
1 Prisoner id Number(1000) Primary key
2 Case id Number(10000) Foreign key
3 Name Varchar2(15) Special characters like
underscore are not allowed.
4 Sex Varchar2(1) M/F
5 Type Varchar2(15) Type of sentence : Duration
specific, life time,
6 Entry-date Date
7 Last-date Date
8 Duration of Number(10000) No of days
sentence
9 Height Number(500) Height in cms
10 Weight Number(700) In Kgs
11 Front-snap <img object>
12 Left-snap <img object>
13 Right-snap <img object>
14 Address Varchar2(15) Permanent address of prisoner
15 Status Number(1) 1: in jail
2:on parole
3: released
4:dead

CASE REGISTER
No. Field Name Type of variable Remarks
1 Case id Number(10000) Primary key
2 Description Varchar2(15) Special characters like
underscore are not allowed.
3 Type Number(1) 1: murder
2: theft
3: forgery
4:counterfeiting
PAROLE REGISTER
No. Field Name Type of variable Remarks
1 Prisoner iD Number(1000) Primary key
2 Name of Reference Varchar2(15) Special characters like
underscore are not allowed.
3 Address of Varchar2(75)
Reference
4 Entry-date Date
5 Exit-date Date
6 Remand frequency Number(100) Should visit Jail for remand
days
7 Last remand visit Varchar2(1) T/F
status
8 Last visited on Date

VISIT TABLE
No. Field Name Type of variable Remarks
1 Visitor id Number(10000) Foreign key
2 Prisoner id Number(1000) Foreign key
3 Visit date Date
4 Start time Time
5 End time Time
6 Status Varchar2(1) For approval and rejection
7 Remarks Varchar2(75) In case of rejection remarks are
mandatory
8 Type Varchar2(1) True : Visitor
False : Jailer – fields 3,4,5 are
invalid

VISITOR’S TABLE
No. Field Name Range of valid values Remarks
for the field
1 Visitor id Number(10000) Primary key
2 Visitor name Varchar2(15).
3 Registered on Date
4 Relation to Prisoner Varchar2(15)
5 Age Number(100) Number
6 Sex Varchar2(1) M/F
7 No of visits Number(1000) Number of visits since
registration
8 Status Varchar2(1) Visitor approval/rejection
9 Remarks Varchar2(15) In case of rejection remarks are
mandatory
 7. Product Functions:
The prison management system should support this
following use-case:

Class of use Actors involved Use cases Description of Use cases

User Account Jailer(admin) Login Login into Account
Usage Old Visitor

Account New Visitor Register Registration for a New account

Management
Jailer(admin) Issue Account Confirm new registration & Issue
New Account ID
Viewing Data Jailer(admin) View <Extends>
with admin Registers 1. view nominal roll register
privilege 2. view case register
3. view parole register
4. view in-out register
Generating Jailer(admin) Report <Extends>
Reports with Generation 1. Prisoner wise report
admin privilege generation
2. Case wise report generation
3. Visitor wise report generation

Interview Old Visitor Request Request for an interview with a

Request prisoner
Jailer(admin) Confirm Confirm Interview Request

Viewing Release Jailer(admin) View Release Viewing the date wise scheduled
Diary Old Visitor Diary release of prisoners
Changing of Jailer(admin) Change Changing of password of user
password Old Visitor Password account

8. USE CASE DIAGRAM:

 System

PRISONER WISE REPORT GENARATION

CONFIRM INTERVIEW REQUEST

CASE WISE REPORT GENERATION <<extend>>

<<extend>> REPORT GENARATION

JAILER(ADMIN)
VISITOR WISE REPORT GENERATION <<extend>>
VIEW REGISTER
OLD VISITOR
<<extend>>
VIEW NOMINAL ROLL ISSUE ACCOUNT
<<extend>> NEW VISITOR

VIEW CASE REGISTER <<extend>> LOG IN

<<extend>> VIEW RELEASE DIARY

VIEW IN-OUT REGISTER

CHANGE PASSWORD

REQUEST FOR AN INTERVIEW

VIEW PAROLE REGISTER

REGISTER FOR NEW ACCOUNT

B. Specific Requirements:
1. FUNCTIONAL REQUIREMENTS:
We describe the functional requirements by giving various use cases:

1. USE CASE RELATED TO LOGIN:

 Primary actor
All registered users having valid accounts
1) Jailer (admin)
2) Old Visitor

Precondition
INTERNET connection is available and working at it's optimal level

Main scenario
1) Users Access the login Page
2) Provide User ID and Password.
3) Login Validity is checked
4) The user is shown their respective homepage.

Alternate scenario
1) The entered is not valid
2) The user is shown the error page.

2. USE CASE RELATED TO REGISTRATION:

Primary actor
Unregistered New Visitor

Precondition
none

Main scenario

1. The visitor accesses the registration page for new ID.

2. He/she fills up the form and submits.
3. The completeness of data is checked on client side.
4. The Database is updated

Alternate scenario

1. The data completeness check fails and the user is prompted to

provide all details.
 2. The database update fails.

3. USE CASE RELATED TO ISSUE ACCOUNT:

Primary actor
Jailer (admin)

Precondition
1. The Jailer is logged in.
2. The visitor verification is already done.

Main scenario
1. Open list of verified Applicants.
2. Select one entry.
3. If visitor is verified offline then a new visitor account is created.
4. Update database

Alternate scenario
1. The database update fails so the process is restarted.

4. USE CASE RELATED TO VIEW REGISTERS:

Primary actor
Jailer (admin)

Precondition
1. Jailer should be logged in to his account

Main scenario
1. Retrieved the nominal roll register, case register, parole
register, in-out register from the data base.
2. Viewing of data.

Alternate scenario
1. Data retrieval process failed.

5. USE CASE RELATED TO GENERATE REPORTS:

 Primary actor
Jailer (admin)

Precondition
1. Jailer should be logged in to his account

Main scenario
1. Retrieval of data prisoner-wise, case-wise or visitor-wise.
2. Form the retrieved data into printable format.
3. Print out the retrieved data.

Alternate scenario
1. Retrieval of data failed
2. Printing out of retrieved data failed

6. USE CASE RELATED TO INTERVIEW REQUEST:

Primary actor
Old visitor

Precondition
1. Old visitor should be logged into his/her account
2. Old visitor should be navigated to interview request page to get
access the interview request form.

Main scenario
1. Access Interview request page
2. Provide all details.
3. Data completeness is checked.
4. On success the Database is updated.
5. Success page is shown.

Alternate scenario
1. Database Update fails.
2. The data completeness check fails.

7. USE CASE RELATED TO INTERVIEW CONFIRMATION:

Primary actor
 Jailer (admin)

Precondition
Jailer should be logged in to his account to access this option

Main scenario
1. Verification status is checked
2. If OK then it is approved.
3. The database is updated.

Alternate scenario
1. The interview request is not approved.

8. USE CASE RELATED TO VIEWING OF RELEASE DIARY:

Primary actor
All registered users having valid accounts
1) Jailer(admin)
2) Old Visitor

Precondition
1. User must be logged in
2. He/she has to be at his home page

Main scenario
1. Retrieved the release diary information from the data base.
2. Viewing of data.

Alternate scenario
1. retrieval of data failed.

9. USE CASE RELATED TO CHANGING OF PASSWORD:

Primary actor
All registered users having valid accounts
3) Jailer(admin)
4) Old Visitor

Precondition
1. The users should have registered an account with the system.
 2. The users are logged into their account.

Main scenario
1. The System asks for the old password.
2. The User provides his/her old password .
3. After successful match the system asks to enter the new
password.
4. The Database is updated .
5. The Success page is shown.

Alternate scenario
1. The Old password doesn't match and the error page is shown.
2. The Database Update fails .

2. PERFORMANCE REQUIREMENT:

1. Should run on 500 MHz, 256 MB machine.

2. 90% of the responses should be within 2 sec.

3. DESIGN CONSTRAINTS:

1. Security: The files in which the information regarding

Jailer , Visitor, Prisoner should be secured against
malicious deformations.
2. Fault Tolerance: Data should not become corrupted in case
of system crash or power failure.

4. EXTERNAL INTERFACE REQUIREMENTS:

The external interface is a dynamically generated web page with

professional graphics

3. CONCLUSION:
 1. The project has only two users. They are jailor and
visitors.
2. The in and out register will be developed by the queries
from nominal roll register and visitor’s table.
3. The release register will be taken from nominal roll table.
4. All the reports will be generated by using queries from the
given table.

1. Guidelines and References:

http://msdn.microsoft.com
http://java.sun.com
http://www.asp.net

2. Technologies:
1.  MySQL 5.1.5 along with HeidiSQL/phpMyAdmin
2. Eclipse/NetBeans IDE 6.9 with javaEE
3. javaEE 5 API
4. Apache TomCat 7.0.2
5. adobe photoshop cs4
6. MagicDraw UML
7. paint.NET
8. open office 3.2
9. Windows XP professional