prison management system srs
TRANSCRIPT
INFOSYS CAMPUS CONNECT PROGRAM
MEGHNAD SAHA INSTITUTE OF TECHNOLOGY
PRISON MANAGEMENT SYSTEM
Software Requirements Specification
TEAM NAME
GROUP-12TEAM MEMBERS
SWATI KOCHAR (IT)TAMOGHNA MAJUMDAR (CSE)ABHISHEK BHOWMIK (EE)PATANJAL NAG BISWAS (EE)RAJDEEP NAYAK (CSE)RITESH GANGULY (ECE)
MENTOR
MR. INDRANIL DAS
Index & Tables1 | P a g e
1.Introduction:…………………………………………31.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:……………………………………………..7A. overall description:
………………………………………………………...71.product perspective:
………………………………………………….72.software interface:
…………………………………………………….73.hardware interface:
…………………………………………………..84.communication interface:
…………………………………………8
2 | P a g e
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:……………………………………………………131.functional requirements:
………………………………………….132.performance requirements:
……………………………………..183.design constrains:
………………………………………………………18
4.external interface requirement:………………………………18
3.Conclusion:…………………………………………18
1. INTRODUCTION:
3 | P a g e
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:
4 | P a g e
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
5 | P a g e
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).
6 | P a g e
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/phpMyAdmin2. Eclipse/NetBeans IDE 6.9 with javaEE3. javaEE 5 API4. Apache TomCat 7.0.25. adobe photoshop cs46. MagicDraw UML7. paint.NET8. open office 3.29. Windows XP professional
2. Overview : 7 | P a g e
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)
8 | P a g e
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 Explorer6.0 or above
CORE DUO AT 1.6GHZ
512 MB 80 GB
SERVER SIDE
Apache Tomcat 7.0.2
Pentium III at 1GHz
512 MB 4 GB
MySQL 5.1.5 Pentium III at 1GHz
512 MB 2 GB
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 Roll2. Case Registers 3. Interview requests 4. In-out register5. Reports and release diary
9 | P a g e
7. DATABASE FIELD SPECIFICATION:
LOGIN TABLEN0. Field name Type of field Remarks1. Username Varchar2(15) Primary key2. Password Number(10)
NOMINAL ROLL REGISTERNo. Field Name Type of variable Remarks1 Prisoner id Number(1000) Primary key2 Case id Number(10000) Foreign key3 Name Varchar2(15) Special characters like underscore are
not allowed.4 Sex Varchar2(1) M/F5 Type Varchar2(15) Type of sentence : Duration specific,
life time,6 Entry-date Date7 Last-date Date8 Duration of sentence Number(10000) No of days9 Height Number(500) Height in cms10 Weight Number(700) In Kgs11 Front-snap <img object>12 Left-snap <img object>13 Right-snap <img object>14 Address Varchar2(15) Permanent address of prisoner15 Status Number(1) 1: in jail
2:on parole3: released4:dead
CASE REGISTERNo. Field Name Type of variable Remarks1 Case id Number(10000) Primary key2 Description Varchar2(15) Special characters like underscore are
not allowed.3 Type Number(1) 1: murder
2: theft3: forgery4:counterfeiting
PAROLE REGISTERNo. Field Name Type of variable Remarks1 Prisoner iD Number(1000) Primary key2 Name of Reference Varchar2(15) Special characters like underscore are
not allowed.3 Address of Reference Varchar2(75)4 Entry-date Date
10 | P a g e
5 Exit-date Date6 Remand frequency days Number(100) Should visit Jail for remand7 Last remand visit status Varchar2(1) T/F8 Last visited on Date
VISIT TABLENo. Field Name Type of variable Remarks1 Visitor id Number(10000) Foreign key2 Prisoner id Number(1000) Foreign key3 Visit date Date4 Start time Time5 End time Time6 Status Varchar2(1) For approval and rejection7 Remarks Varchar2(75) In case of rejection remarks are
mandatory8 Type Varchar2(1) True : Visitor
False : Jailer – fields 3,4,5 are invalid
VISITOR’S TABLENo. Field Name Range of valid values for the
fieldRemarks
1 Visitor id Number(10000) Primary key2 Visitor name Varchar2(15).3 Registered on Date4 Relation to Prisoner Varchar2(15)5 Age Number(100) Number
6 Sex Varchar2(1) M/F7 No of visits Number(1000) Number of visits since registration8 Status Varchar2(1) Visitor approval/rejection9 Remarks Varchar2(15) In case of rejection remarks are
mandatory
8. 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 Usage
Jailer(admin)Old Visitor
Login Login into Account
Account Management
New Visitor Register Registration for a New account
Jailer(admin) Issue Account Confirm new registration & Issue
11 | P a g e
New Account IDViewing Data with admin privilege
Jailer(admin) View Registers
<Extends>1. view nominal roll register2. view case register3. view parole register4. view in-out register
Generating Reports with admin privilege
Jailer(admin) Report Generation
<Extends>1. Prisoner wise report
generation2. Case wise report generation3. Visitor wise report generation
Interview Request
Old Visitor Request Request for an interview with a prisoner
Jailer(admin) Confirm Confirm Interview Request
Viewing Release Diary
Jailer(admin) Old Visitor
View Release Diary
Viewing the date wise scheduled release of prisoners
Changing of password
Jailer(admin) Old Visitor
Change Password
Changing of password of user account
9. USE CASE DIAGRAM:
12 | P a g e
System
JAILER(ADMIN)
OLD VISITOR
NEW VISITOR
LOG IN
REGISTER FOR NEW ACCOUNT
ISSUE ACCOUNT
VIEW REGISTER
REPORT GENARATION
VIEW RELEASE DIARY
REQUEST FOR AN INTERVIEW
CONFIRM INTERVIEW REQUEST
VIEW NOMINAL ROLL
VIEW CASE REGISTER
VIEW PAROLE REGISTER
VIEW IN-OUT REGISTER
<<extend>>
<<extend>>
<<extend>>
<<extend>>
PRISONER WISE REPORT GENARATION
CASE WISE REPORT GENERATION
VISITOR WISE REPORT GENERATION
<<extend>>
<<extend>>
<<extend>>
CHANGE PASSWORD
B. Specific Requirements:
1. FUNCTIONAL REQUIREMENTS:
13 | P a g e
We describe the functional requirements by giving various use cases:
1. USE CASE RELATED TO LOGIN:
Primary actorAll registered users having valid accounts
1) Jailer (admin)2) Old Visitor
PreconditionINTERNET 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 actorUnregistered New Visitor
Preconditionnone
Main scenario
1. The visitor accesses the registration page for new ID. 2. He/she fills up the form and submits.
14 | P a g e
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 actorJailer (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 scenario1. The database update fails so the process is restarted.
4. USE CASE RELATED TO VIEW REGISTERS:
Primary actorJailer (admin)
Precondition1. Jailer should be logged in to his account
15 | P a g e
Main scenario1. Retrieved the nominal roll register, case register, parole
register, in-out register from the data base.2. Viewing of data.
Alternate scenario1. Data retrieval process failed.
5. USE CASE RELATED TO GENERATE REPORTS:
Primary actorJailer (admin)
Precondition 1. Jailer should be logged in to his account
Main scenario1. 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 scenario1. Retrieval of data failed2. Printing out of retrieved data failed
6. USE CASE RELATED TO INTERVIEW REQUEST:Primary actorOld visitor
Precondition1. Old visitor should be logged into his/her account2. Old visitor should be navigated to interview request page to get
access the interview request form.
Main scenario
16 | P a g e
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 actorJailer (admin)
PreconditionJailer 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 scenario1. The interview request is not approved.
8. USE CASE RELATED TO VIEWING OF RELEASE DIARY:Primary actorAll registered users having valid accounts
1) Jailer(admin)2) Old Visitor
Precondition1. User must be logged in2. He/she has to be at his home page
17 | P a g e
Main scenario1. Retrieved the release diary information from the data base.2. Viewing of data.
Alternate scenario1. retrieval of data failed.
9. USE CASE RELATED TO CHANGING OF PASSWORD:Primary actorAll 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.
18 | P a g e
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.
19 | P a g e