PRISON MANAGEMENT SYSTEM

Department of Computer Sciences

Submitted By:

Muslim Mir (6029)

Murad Ali (5993)

Salman Karim (6028)

M.Salman Khan (5995)

Amir Muneeb (4854)

BS-SE (5th Semester) Sec-A

Submitted To:
Mr. Kashif Basir (Lecturer CS Department)

City University of Science and Information Technology

Peshawar

1
Table of Contents
Vision and Scope Document....................................................................................... 5
1. BUISSNESS REQUIRMENT:.................................................................................... 5
1.1 BACKGROUND:............................................................................................... 5
1.2 BUISNESS OPPORTUNITY:............................................................................... 5
1.3 BUISNESS OBJECTIVEES AND SUCCESS CRITERIA:.........................................5
1.4 CUSTOMER OR MARKET NEEDS:.....................................................................6
1.5 BUISNESS RISKS:............................................................................................ 6
2: VISION OF THE SOLUTION:..................................................................................7
2.1 VISION STATEMENT:........................................................................................ 7
2.2 MAJOR FEATURES:.......................................................................................... 7
2.3 ASSUMPTIONS & DEPENDENCIES:..................................................................8
3. SCOPE AND LIMITATION:...................................................................................... 8
3.1, 3.2 SCOPE OF INITIAL AND SUBSEQUENT RELEASE:......................................9
3.3 LIMITATION & EXCLUSION:..............................................................................9
4. BUISNESS CONTEXT:............................................................................................ 9
4.1 STAKE HOLDER PROFILES:............................................................................10
4.2 PROJECT PRIORITIES:.................................................................................... 10
4.3 OPPERATING ENVIRONMENT:........................................................................11
UML Diagrams.......................................................................................................... 12
Data Flow Diagram:............................................................................................... 12
Level 0:.............................................................................................................. 12
Level 1:.............................................................................................................. 13
Level 2:.............................................................................................................. 14
Level 3:.............................................................................................................. 15
Level 4:.............................................................................................................. 15
Entity-Relationship Diagram:................................................................................. 17
State Transition Diagram:...................................................................................... 18
Dialog Map:........................................................................................................... 21
Class Diagram:...................................................................................................... 22
Decision Tables and Decision Trees:......................................................................24

2
 Use Case Diagram:................................................................................................ 25
Activity Diagram:................................................................................................... 27
Sequence Diagram:............................................................................................... 29
Software Requirement Specification.........................................................................31
1. Introduction:.................................................................................................... 31
1.1 Purpose:....................................................................................................... 31
1.2 Document Conventions:...............................................................................31
1.3 Intended Audience and Reading Suggestions:.............................................31
1.4 Project Scope:.............................................................................................. 31
1.5 Reference:.................................................................................................... 31
2. Overall Description:........................................................................................ 31
2.1 Product Perspective:..................................................................................... 32
2.2 Product Features:......................................................................................... 32
2.3 User Classes and Characteristics:................................................................32
2.4 Operating Environment:............................................................................... 32
2.5 Design and Implementation Constraints:.....................................................32
2.6 User Documentation:................................................................................... 33
2.7 Assumptions and Dependencies:.................................................................33
3 System Features:................................................................................................ 33
3. x System Feature X:....................................................................................... 33
4 External Interface Requirements:.......................................................................34
4.1 User Interfaces:............................................................................................ 34
4.2 Hardware Interfaces:.................................................................................... 34
4.3 Software Interfaces:..................................................................................... 35
4.4 Communication Interfaces:..........................................................................35
5 Other Nonfunctional Requirements:...................................................................35
5.1 Performance Requirements:.........................................................................35
5.2 Safety Requirements:................................................................................... 36
5.3 Security Required:........................................................................................ 36
5.4 Software Quality Attributes:.........................................................................36
6 Other Requirements:.......................................................................................... 36
Appendix A: Glossary:............................................................................................ 36
Appendix B: Analysis Models:................................................................................36

3
 Appendix C: Issues List:......................................................................................... 37

Vision and Scope Document

4
 further case. For the interior minister they can get all the details from
this prison management system on one click if these are other request
from jailer out-of-scope then these request will be checked if these
request or valuable ,they will be added otherwise rejected.

3.1, 3.2 SCOPE OF INITIAL AND SUBSEQUENT RELEASE:

Feature Release 1 Release 2
FE-1: The requirement like Features like medical
Name, types of report of a prison are
crime, age, address, hard to add at initial
location which are release so we will add it
very essential they now.
should be
implemented at initial
release.

FE-2: Not implemented Fully Implemented

FE-3: Prisoner’s details should be Details should also be given to
given to the jailor and the affiliated lawyers related
interior minister. to the different cases.
FE-4: To record the daily base
schedule of the policemen
and provide the report to
the jailor on weekly base.
FE-5 To show the time table for
food of the prisoner’s.
FE-6 To provide weekly base
medical report and working
credit hours of a prisoner’s in a
prison.

3.3 LIMITATION & EXCLUSION:

LI-1: The features like prisoner details ,policemen, jailor, lawyer

are present in the scope if a jailor wants a new features like

9
 having a yearly record of smuggle things e.g. drugs,
weapons, etc. so as we know that they are not in scope but
important so we add that features in a software but will take
extra cost and time .
LI-2: TBD

4. BUISNESS CONTEXT:
The project business issues are to record the details of the prisoners,
jailors and the lawyer and the prison we will include the profiles of
major stake holders like developers, analyst customers, and head of
organization etc.

4.1 STAKE HOLDER PROFILES:

We should add the records of different stakeholders like a developer
name and he is interested is designing and has directly affected by a
loss or profit. We should also add a profile. We should also add a profile
of requirement analyst and other like coder, etc.

Stakeholder Benefit Attitude Constraint Interest

Jailer Benefit from Attitude of This system The Jailer
this system the jailer must be may have
for jailer is, should be reliable and interest to
that he can positive provide access all
access, towards this reports of and
search, system. prisoners individual
delete, and without error. record by one
update the click.
record of all
prisoners.
Lawyer The Lawyer Should be The system The lawyers
can get the positive as should may have
complete the lawyers provide interest to
report of his can access complete bio have the final
concern the records data of the report of
prisoner. which will prisoners to prisoners so
help them in the lawyers. that they can
their cases. proceed
further.

10
 Interior He can Should be The Minister He will have
Minister access the positive as should also interest as he
individual he can be provided can get and
record if he access the with the report the
want to know records complete prisoners’
about any which he data he records for
prisoner bio wants for his wants. his use.
data. use.

4.2 PROJECT PRIORITIES:

Our five areas in this scope or features the quality of a software, the
estimated time ,its cost and the staff required to build up that software
we will put these areas in a following these categories.

We use these priorities to classify them in these categories the first

which are essential and must be implemented in the project. The
second which are essential but not much as the first one (i.e. a
constraint) .The third one which have no importance but they are just
added for the customers satisfactions.

Dimensi Driver Constraint Degree of Freedom

on
Schedul As this system is
e building for the Prison
for the first time to
replace the manual
system so it could go
beyond the planned
‘schedule’.
Feature Here all the
s authorities are will
developers who will
decide to exclude the
unimportant
‘features’ in initial
release like if they
want a software in
two months but we

11
 will take much time.

Quality Features like report

will be in a
constraint, ‘quality’
must be taken in a
constraint.
Staf We hire a ‘staff’ of 20
people instead of 10
to build a reliable and
error free system.
Cost If they demand
for the medical
report of the
prisoners .we
will check it if
it’s ‘cost’ is not
too much
expensive then
we will
implement
that feature for
him.

4.3 OPPERATING ENVIRONMENT:

The system will work only in the prison or in such area where rules and
low are enforced.

We will ask the stakeholders the following question i.e. Are the users of
this system present in different cities of the country or in the same and
how many prisons of the country of different cities are connected
through this system?

12
UML Diagrams
Data Flow Diagram:
A data flow diagram (DFD) is a graphical representation of the
"Stream" of data through an information system, modeling its process
aspects. A DFD is frequently utilized as a preparatory step to make a review
of the system, which can later be elaborated. DFDs can likewise be utilized
for the representation of data processing (structured design).

Expected Users:

Interior Minister, Jailer, Lawyer and the prisoner but the prisoner will
interact with jailer to ask for prisoner details.

Level 0:
Example:

Figure 1 is a level 0 Data Flow Diagram (DFD) which illustrates the

initial requirements (business requirements) Prison Management System. It
includes the details about user which are; Interior Minister, Jailer, Lawyer and
the Prisoner in which the user requests to the system and result is shown.

13
 Figure 1

Level 1:
Example:

Figure 2 is a level 1 Data Flow Diagram (DFD) which illustrates the

record of prisoner in which user can; Add, Update, Delete, Generate report,
Preview prisoner details, Edit police men details.

Figure 2

Level 2:
Example:

Figure 3 is a level 2 Data Flow Diagram (DFD) which illustrates the user
check the details of; Prisoner, Lawyer and Jailer.

14
 Figure 3

Level 3:
Example:

Figure 4 is a level 3 Data Flow Diagram (DFD) which illustrates the user
can preview; Prisoner details and Case details.

Figure 4

Level 4:
Example:

15
 Figure 5 is a level 4 Data Flow Diagram (DFD) which illustrates the
Prisoner request for details which includes his Crime, Punishment and Case
details.

Figure 5

16
 Figure 6

Entity-Relationship Diagram:
An Entity-Relationship Diagram, or ERD, is a chart that visually shows
the relationship between database elements. ERDs model an organization's
data storage necessities with three primary segments: entities, attributes,
and relationships.

Example:

Figure 7 is an Entity-Relationship Diagram, or ERD which illustrates the

relationship between the entity; Jailer, Prisoner, Lawyer, PMS and Interior
Minister.

17
 Figure 7

Figure 8

State Transition Diagram:

State transition diagram have been utilized right from the earliest
starting point as a part of object-oriented modeling. The essential thought is
to characterize a machine that has various states (thus the term finite state
machine). The machine gets events from the outside world, and every event
can bring about the machine to move transition with one state then onto the
next.

Example:

Figures 9(a) & (b) are State Transition Diagrams which illustrates the
different states of the PMS in between the jailer, interior minister, victim, FIR,
and Prisoner.

18
Figure 9(a)

19
 Figure 9(b)

Notations:

20
 Figure 10

Dialog Map:
Demonstrates a user interface (screens, windows, dialog boxes, HTML
pages) and the possible navigation paths among the interfaces components.

Example:

Figure 11 is a Dialog Map which illustrates the external behavior of the

PMS. How the user like Jailer, Interior Minister, Prisoner and Lawyer interact
with the PMS.

21
 Figure 11

Class Diagram:
A class diagram is an outline of the relationships and source code
dependencies among classes in the Unified Modeling Language (UML). In this
context, a class characterizes the methods and variables in an object, which
is a particular entity in a program or the unit of code representing to that
entity.

Example:

A figure 12 is a Class Diagram which illustrates the different classes

and their objects in the PMS.

22
 Figure 12

Notations:

23
 Figure 13

Decision Tables and Decision Trees:

A decision tree is a graphical method for representing the steps
included in settling on a choice.

A user can look at a decision tree that depicts a decision process they
utilize and recognize any blunders in the diagram.

Every horizontal "branch" of the tree represents the result of a decision

or a progression of decisions.

Example:

Figure 14 is a Decision Table and Decision Trees which illustrates the

Decision making at different stages in the PMS.

24
 Figure 14

Use Case Diagram:

A use case diagram at its simplest is a representation of a user's
interaction with the framework that demonstrates the relationship between
the user and the different use cases in which the user is involved. A use case
diagram can recognize the different types of users of a system and the
different use cases and will frequently be accompanied by other types of
diagrams as well.

Example:

Figure 15 is a use case diagram which illustrate the interactions

between PMS, Jailer, Interior Minister, Lawyer and Prisoner.

25
Figure 15

26
 Figure 16

Activity Diagram:
Activities diagrams are graphical representations of work processes of
stepwise exercises and actions with backing for decision, emphasis and
simultaneousness. In the Unified Modeling Language, movement outlines are
planned to display both computational and authoritative procedures (i.e.
workflows). Activity charts demonstrate the general stream of control.

EXAMPLE:

Figure 17 illustrate that it include the details about login process if an

id is valid then login success and search the record if record is found then
generate the searched report. If not found then enter the new record.

27
Figure 17

28
 Figure 18

Sequence Diagram:
A Sequence diagram is a connection chart that shows how procedures
work with each other and in what request. It is a build of a Message
Sequence Chart. A sequence diagram shows object collaborations
orchestrated in time arrangement. It portrays the articles and classes
included in the situation and the succession of messages traded between the
items expected to do the situation's usefulness. Arrangement graphs are
normally connected with use case acknowledge in the Logical View of the
framework a work in progress. Succession outlines are now and then called
occasion charts or occasion situations.

EXAMPLE:

Figure 19 illustrate that user executes the PMS system then the user
will be prompt to login after that the user is logged in the request is granted

29
to the user then the data sequence is ready the next sequence will start PMS
system working.

Figure 19

Notations:

Figure 20

30
Software Requirement Specification
1. Introduction:
The SRS will give the complete detail of P.M.S and it will help the
stakeholder to understand the product.

1.1 Purpose:
This is the prison management system and the purpose of this
system is to record the details of the data in computerized form
not like a previous way i.e. Manual form.

1.2 Document Conventions:

The font size of the text will be 12 and the heading size will be 18
and theme of the font will be (Calibri) and the color should be
black.

1.3 Intended Audience and Reading Suggestions:

Following are the list of the readers to whom the SRS list will be
directed:

1) Project Manager

2) Interior Minister

3) Jailor

4) Developer

1.4 Project Scope:

It will keep the record of the prisoners i.e. the jailor, the police
men and the other employees working in the prison “Scope “ in
the prison management system is that for the jailors it will record
all the details of the prisoners ,lawyers can access the reports of
the prisoners to do further case. For the interior minister they
can get all the details from this prison management system on
one click if these are other request from jailer out-of-scope then
these request will be checked if these request or valuable ,they
will be added otherwise rejected.

31
 1.5 Reference:
The project will be linked with a Google map and it will show the
locations of different branches of the prisons. In this project we
are using the IEEE standard.

2. Overall Description:
To record the details of Prisoners and Jailors, policemen, cells,
crime details etc. The constraints are: We will use .Net
Framework to establish this software. The software will only run
on windows Operating System. The documentation should be
recorded in English language.

2.1 Product Perspective:

We are replacing the existing one that is the manual system with
computerized system. The origin of this product will be the jailor.

2.2 Product Features:

The main features of this product are; that it records the details
of prisoner, generate the report on monthly basis, it saves,
record, delete and can make changes in it.

2.3 User Classes and Characteristics:

User Description
Class
Jailor The jailor can record the details about prisoner.
Prisoner The prisoner can also see his record through jailor or
his lawyer.
Interior The interior minister can see the monthly or daily
Minister basis report of the prison
Lawyer The lawyer can see the report of the specific prisoner
if he has taken permission from the court.

2.4 Operating Environment:

OE-1 All the coding will be written in C# programming
language.
OE-2 It will be operated only on windows operating system
OE-3 We must use MySQL database engine.
OE-4 This software will be used in overall region of a
country in different branches of prison.

32
2.5 Design and Implementation Constraints:
CO-1 We will use .Net Frame Work and C# programing
language
CO-2 In this product MySQL will be used as a database.
CO-3 We will use a developer coding style. So that each
developer can do his own standard style.
CO-4 It has no backward compatibility with earlier product
because it’s the first computerized system.
CO-5 It will be compatible on both the 32bit and 64bit
operating system.

2.6 User Documentation:

UD-1 We will deliver a user manual along with this
software that will help user to understand the
system.

2.7 Assumptions and Dependencies:

AS-1 With the prison management system the jailor may

expect that he want software along with a website.
AS-2 The jailor may want the medical report of the
prisoner for the purpose of remand.

AS-3 As this system is for Government Organization, so

the Customer may want also NADRA system
included.

3 System Features:
3. x System Feature X:
The features will be named as below:

33
“Record” feature will be named as 3.1 and its subsections like updating the
record will be named as “3.x.1”

3. X.1 Description and Priority:

The feature like “record” is used to record a new data and update a changes
in it.It will be indicate as high priority in a product.

3. x.2 Stimulus/Response Sequence:

Stimulus The Jailer enter the record of prisoner and press the
ADD button
Respons The system in response shows the dialog box that the
e record has been saved.
Stimulus The Jailer wants to update the prisoner record. So he
presses the UPDATE button.
Respons The system in response will show the dialog box that
e the record has been updated.
Stimulus The Interior Minister wants to know the prisoner
report. So he presses the REPORT button.
Respons The system in response will generate the report of that
e specific prisoner

3. X.3 Functional Requirements:

FR-1 If the user input is incorrect then the system in
response will show the dialogue box that the input
u enters is invalid.
FR-2 if the user(jailer) will enter the age of a prisoner
less than 18 then the system will show a dialogue
box showing that the prisoner age must be 18 or
above.

FR-3 If the password of the user is incorrect then the

system will not open.

4 External Interface Requirements:

Here the hardware interface will be the computer system which
will communicate properly with the prison management system. Our
software the (P.M.S) will be connected with a database i.e. MySQL.

34
4.1 User Interfaces:
UI-1 The size of font will be default that is 12 and the
font style will be Arial the color will be black and
the buttons will be of circle and rectangular shape.
UI-2 The screen resolution will be 720p
UI-3 On ctrl+s the file will be saved and on ctrl+o it will
be open and on ctrl+q it will exit the file etc.

4.2 Hardware Interfaces:

There is no direct interface between P.M.S and computer system.

4.3 Software Interfaces:

SI-1 Our software will run on windows operating system.
SI-2 It will connect with MySQL database.

SI-3 The jailor can add and update the record of

prisoners.
SI-4 The interior minister can generate the monthly and
weekly report of the prisoners.

4.4 Communication Interfaces:

CI-1 The system will email to the interior minister
about the monthly report of the prison.

CI-2 The system will also send email to the jailor about
the specific case of the prisoner.

5 Other Nonfunctional Requirements:

The software will be secure, reliable and reusable.

35
5.1 Performance Requirements:
PE-1 “90% of data will be retrieve (database query) in 5
seconds on a single user 2.1-GHZ Intel Core i 3
running Windows 8 with at least 70 percent of the
system resources free.”

PE-2 The confirmation message should be displayed in

less than 5 sec after Jailer Stimulus.

5.2 Safety Requirements:

SF-1 The product will not open when a firewall is not

open.
SF-2 The data will automatically save after every 5mins
in a case any lose because of power off or system
crash etc.

5.3 Security Required:

SR-1 It will take a username and password from every
User to enter into the software system.
SR-2 If the username or password will be incorrect then
it will not enter into the system

5.4 Software Quality Attributes:

Efficiency Our software will be efficient over portability.
Security Our software will be secured over reusability.

36
6 Other Requirements:
Fine payment will be written in Pakistani Rupees. We will use
English (US) language.

Appendix A: Glossary:
The developer should know about the abbreviation of P.M.S that is
prison management system.

Appendix B: Analysis Models:

We have attached the complete UML diagrams in a doc file.

Appendix C: Issues List:

The feature like generating a medical report will be added in a next
release and it will be mark as TBD.

37