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
1. BUISSNESS REQUIRMENT: To record the details of Prisoners and Jailors, policemen, cells, crime details etc.
1.1 BACKGROUND: At initial stage we had got a manual system .In which it was hard to search a single data of any prisoner, overwriting and time consuming, chance of data loss, too much space occupied because of too many registers which are present in hard form and it was non secure, because of these draw back we introduce a solution for it by building /constructing a software for the prison which keep all those records in efficient way. It will be easy to access no tendency problem, full secure and easily searchable.
1.2 BUISNESS OPPORTUNITY: It will be beneficial in a data loss case because we should have a backup system for it. It can be accessible from any prison .It has solved our security, redundancy and searching process problems. It was not much space occupied like the previous system all the data will be stored in a single database system.
1.3 BUISNESS OBJECTIVEES AND SUCCESS CRITERIA: For the developers the major point of the success of product will be, to fulfill the needs and expectations of the customers and for the users major point of success will be that it can be modifiable and its performance should be efficient.
BO-1: BO-2: BO-3:
Reduce the loss of record by 90% so if we loss record so we would have a backup system. To deliver a fully functional system that delivers close to 100% efficiency in prisons management in a city. To bring in maximum accuracy in the prison management in all key functional and operational areas; to overcome the manual system in the process of remission 5
BO-4:
Make the work profile of staff much easier and smooth in day-to-day administrative work. It can be modifiable and its performance should be efficient. Achieve an increase in data efficiency by 70% within 4 months following initial release and 90% within 8 months following initial release.
SC-1: SC-2:
FINANCIAL: Our estimation about the sale of this product is that, this product will capture a market share of 80% within 6 months, because it will be easy to use, easy to enter new record and easily, understandable. This Computerized system was introduced because in current manual system data redundancy could occur and risk of losing data is high.
NON FINANCIAL: It will be good rated because of such requirements that fulfill all the needs for a long period. This system is more reliable as compared to the current manual system.
1.4 CUSTOMER OR MARKET NEEDS: If a customer expects a record of that prisoner which is ill and is in the hospital, this is not present in current software.
1.5 BUISNESS RISKS: The main risk in development is that will the software work as expected and will it be delivered in a time within the defined budget .If we will reject to make project so it will affect our market reputation. If this system doesn’t respond quickly then it will affect our expected market share. RI-1:
Loss of prisoners data because of improper records
RI-2:
Inaccurate records of prisoners data 6
RI-3:
Prisoners are placed in remand for a long time without trial because of loss of data.
2: VISION OF THE SOLUTION: We are making the prison project for the city prison.
2.1 VISION STATEMENT: “For” a jailor and interior minister. “Who” need to record the brief details of the prisoner? ”The” prison management system. ”Is” a record keeping system. ”That” will provide all the details of the prisoners to the jailor, interior minister and affiliated lawyer. The system will keep the record of the prisoner which includes his crime background, age, cast, address, medical report and also the number of cells and prisoners. “Unlike” the manual current record keeping system. “Our” product will provide the complete report of the prisoners to the jailor, interior minister and the lawyer on the basis of these reports they will do further investigation .
2.2 MAJOR FEATURES: FE-1:
Detail information of all prisons can be stored in single place
FE-2:
Can search, create, delete and update all the prisoners’ records.
7
FE-3:
Will use unique labels like astaric (*) to record the details of a prisoner as a functional requirement and access the record of the prisoners in the form of report as a user requirement.
FE-4:
Daily basis Lock in/Lock up register.
FE-5:
Daily base sick register.
FE-6:
Tracking and monitoring facility for “Prison Death”, “Prison Escape” etc.
FE-7:
Each prison will have their own interface with the facility to deal all data related to them which can be access by their prison ID.
FE-8
Can search, delete, create and update all the jailors record.
2.3 ASSUMPTIONS & 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.
DE-1:
As this system is for Government Organization, so the Customer may want also NADRA System included.
3. SCOPE AND LIMITATION: 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 8
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 FE-1:
FE-2: FE-3:
FE-4:
FE-5
Release 1 The requirement like Name, types of crime, age, address, location which are very essential they should be implemented at initial release.
Release 2 Features like medical report of a prison are hard to add at initial release so we will add it now.
Not implemented Prisoner’s details should be given to the jailor and interior minister. To record the daily base schedule of the policemen and provide the report to the jailor on weekly base. To show the time table for food of the prisoner’s.
Fully Implemented Details should also be given to the affiliated lawyers related to the different cases.
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
LI-2:
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 . 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 Jailer
Lawyer
Benefit Benefit from this system for jailer is, that he can access, search, delete, and update the record of all prisoners. The Lawyer can get the complete report of his concern prisoner.
Attitude Attitude of the jailer should be positive towards this system.
Constraint This system must be reliable and provide reports of prisoners without error.
Interest The Jailer may have interest to access all and individual record by one click.
Should be positive as the lawyers can access the records which will help them in their cases.
The system should provide complete bio data of the prisoners to the lawyers.
The lawyers may have interest to have the final report of prisoners so that they can proceed further.
10
Interior Minister
He can access the individual record if he want to know about any prisoner bio data.
Should be positive as he can access the records which he wants for his use.
The Minister should also be provided with the complete data he wants.
He will have interest as he can get and report the prisoners’ records for his 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 on Schedul e
Feature s
Driver
Constraint
Degree of Freedom As this system is building for the Prison for the first time to replace the manual system so it could go beyond the planned ‘schedule’. Here all the 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
Cost
We hire a ‘staff’ of 20 people instead of 10 to build a reliable and error free system. 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 Class Jailor
Description
Prisoner
The prisoner can also see his record through jailor or his lawyer. The interior minister can see the monthly or daily basis report of the prison The lawyer can see the report of the specific prisoner if he has taken permission from the court.
Interior Minister Lawyer
The jailor can record the details about prisoner.
2.4 Operating Environment: OE-1 OE-2 OE-3 OE-4
All the coding will be written in C# programming language. It will be operated only on windows operating system We must use MySQL database engine. 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 CO-2 CO-3 CO-4 CO-5
We will use .Net Frame Work and C# programing language In this product MySQL will be used as a database. We will use a developer coding style. So that each developer can do his own standard style. It has no backward compatibility with earlier product because it’s the first computerized system. 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 AS-2
AS-3
With the prison management system the jailor may expect that he want software along with a website. The jailor may want the medical report of the prisoner for the purpose of remand. 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 Respons e Stimulus Respons e Stimulus Respons e
The Jailer enter the record of prisoner and press the ADD button The system in response shows the dialog box that the record has been saved. The Jailer wants to update the prisoner record. So he presses the UPDATE button. The system in response will show the dialog box that the record has been updated. The Interior Minister wants to know the prisoner report. So he presses the REPORT button. The system in response will generate the report of that specific prisoner
3. X.3 Functional Requirements: FR-1
FR-2
FR-3
If the user input is incorrect then the system in response will show the dialogue box that the input u enters is invalid. 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. 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
UI-2 UI-3
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. The screen resolution will be 720p 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. The interior minister can generate the monthly and weekly report of the prisoners.
SI-4
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 SF-2
The product will not open when a firewall is not open. 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
