BYTE BREAKERS 2011

PRISON MANAGEMENT SYSTEM

Software Requirements Specification

TEAM NAME
BYTE BREAKERS

TEAM MEMBERS
TEAM MEMBERS
S.INDHU
C.P.ANNAMMA ANGEL
T.ABINAYA
R.VIDHYA

MENTOR

MR.S.K.SENTHIL KUMAR

1| Page
BYTE BREAKERS 2011

Index & Tables

1. Introduction:««««««««««««««««3
1.1 purpose:«««««««««««««««««««««««««««3
1.2 scope:««««««««««««««««««««««««««««..4
1.3 keyword used:«««««««««««««««««««««««.4
1.4 abbreviation used:««««««««««««««««««««..5
1.5 guideline & references:««««««««««««««««««6
1.6 technologies used:«««««««««««««««««««««6
2. Overview:«««««««««««««««««..7
A. overall description:«««««««««««««««««««««...7
1. product perspective:«««««««««««««««««««.7
2. software interface:««««««««««««««««««««.7
3. hardware interface:«««««««««««««««««««..8
4. communication interface:««««««««««««««««8
5. users of the system:««««««««««««««««««««.8
6. functional components:«««««««««««««««««..8
7. database field specifications:««««««««««««««.9
8. product functions:«««««««««««««««««««««11
9. use case diagram:««««««««««««««««««««..12
B. specific requirements:««««««««««««««««««««13
1. functional requirements:««««««««««««««««.13
2. performance requirements:««««««««««««««..18
3. design constrains:«««««««««««««««««««««18
4. external interface requirement:««««««««««««18
3. Conclusion:««««««««««««««««18

2| Page
BYTE BREAKERS 2011

1. INTRODUCTION:

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.

3| Page
BYTE BREAKERS 2011

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) KEYWORDS USED:

Generic Technology keywords:

1. Operating System

2. Databases

3. Programming

4. Software Engineering

4| Page
BYTE BREAKERS 2011

1.4) ABBREVIATIONS 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/NetBeans: 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.

#Servlets: 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).
5| Page
BYTE BREAKERS 2011

__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.

1.5) Guidelines and References:

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

1.6) 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

6| Page
BYTE BREAKERS 2011

2. Overview :
SRS will include two sections:
%
_ _Overall Description will describe major components of the
system, interconnection and external interfaces.
&
_ _Specific Requirements will describe the functions of actors, their
role in the system and constraints.

A. Overall Description:
Describe the general factors that affect the product and its requirements.

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. Software Interface:
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)

7| Page
BYTE BREAKERS 2011

Development End: NetBeans (J2EE, Java, Java Bean, Servlets,

HTML), Database server (MySQL), OS (Windows XP professional),
Apache Tomcat (Web Server).

3. Hardware Interface:
CLIENT SIDE
PROCEESOR RAM DISK SPACE
Internet CORE DUO AT 512 MB 80 GB
Explorer 1.6GHZ
6.0 or above
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

4. Communication Interface:
#_Client on Internet will be using HTTP/HTTPS protocol.

#_Client on Intranet will be using TCP/IP protocol.

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

2. Visitor

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

8| Page
BYTE BREAKERS 2011

7. DATABASE FIELD SPECIFICATION:

LOGIN TABLE
N0. Field name Type of field Remarks
1. Username Varchar2(15) Primar y 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
underscor e are not allowed.
4 Sex Varchar2(1) M/F
5 Type Varchar2(15) Type of sentence : Duration
specific, life time,
6 Entr y-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) Per manent 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 Descr iption Varchar2(15) Special characters like
underscor e are not allowed.
3 Type Number (1) 1: murder
2: theft
3: forgery
4:counterfeiting

9| Page
BYTE BREAKERS 2011

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
underscor e are not allowed.
3 Address of Varchar2(75)
Reference
4 Entr y-date Date
5 Exit-date Date
6 Remand fr equency Number (100) Should visit Jail for remand
days
7 Last r emand 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

10 | P a g e
BYTE BREAKERS 2011

8. Product Functions:
The prison management system should support this
following use-case:

Class of use Actors involved Use cases Descriptio n of Use cases

User Account Jailer(ad min) Login Login into Account

Usage Old Visitor

Account New Visitor Register Registration for a New account

Management
Jailer(ad min) 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-o ut 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

11 | P a g e
BYTE BREAKERS 2011

9. USE CASE DIAGRAM:

S yst e m

PRISONER WISE REPORT GENARATION

CONFIRM INTERVIEW REQUEST

<<e xte nd>>

CASE WISE REPORT GENERATION

<<e xtend>> REPORT GENARATION

JAILER(ADMIN)
<<extend>>
VISITOR WISE REPORT GENERATION
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

12 | P a g e
BYTE BREAKERS 2011

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

13 | P a g e
BYTE BREAKERS 2011

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)
14 | P a g e
BYTE BREAKERS 2011

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
15 | P a g e
BYTE BREAKERS 2011

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
16 | P a g e
BYTE BREAKERS 2011

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 .

17 | P a g e
BYTE BREAKERS 2011

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.

18 | P a g e