Professional Documents
Culture Documents
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
2| Page
BYTE BREAKERS 2011
1. INTRODUCTION:
1.1) PURPOSE:
3| Page
BYTE BREAKERS 2011
1.2) SCOPE:
3. System should support for Data Entry module for Nominal Roll,
Case register for each prisoner entering in the prison.
1. Operating System
2. Databases
3. Programming
4. Software Engineering
4| Page
BYTE BREAKERS 2011
#GUI: Graphical User interface with the system with mouse control and
other easy to use control features like the menus etc.
#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.
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)
7| Page
BYTE BREAKERS 2011
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.
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
LOGIN TABLE
N0. Field name Type of field Remarks
1. Username Varchar2(15) Primar y key
2. Password Number(10)
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:
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
S yst e m
CHANGE PASSWORD
12 | P a g e
BYTE BREAKERS 2011
B. Specific Requirements:
1. FUNCTIONAL REQUIREMENTS:
We describe the functional requirements by giving various use cases:
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.
Primary actor
Unregistered New Visitor
Precondition
none
13 | P a g e
BYTE BREAKERS 2011
Main scenario
Alternate scenario
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.
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.
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
Precondition
1. Old visitor should be logged into his/her account
15 | P a g e
BYTE BREAKERS 2011
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.
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.
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.
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:
3. DESIGN CONSTRAINTS:
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