This document provides a software requirements specification for a prison management system. The system aims to develop modules for nominal roll, case register, parole register, interview requests, in-out register, and an automated release diary generator. It will allow police officials, data managers, and administrators to manage prisoner data and generate various reports. The system is intended to effectively manage prisons through the collection and organization of prisoner information and records.
Copyright:
Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online from Scribd
This document provides a software requirements specification for a prison management system. The system aims to develop modules for nominal roll, case register, parole register, interview requests, in-out register, and an automated release diary generator. It will allow police officials, data managers, and administrators to manage prisoner data and generate various reports. The system is intended to effectively manage prisons through the collection and organization of prisoner information and records.
This document provides a software requirements specification for a prison management system. The system aims to develop modules for nominal roll, case register, parole register, interview requests, in-out register, and an automated release diary generator. It will allow police officials, data managers, and administrators to manage prisoner data and generate various reports. The system is intended to effectively manage prisons through the collection and organization of prisoner information and records.
Copyright:
Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online from Scribd
This document provides a software requirements specification for a prison management system. The system aims to develop modules for nominal roll, case register, parole register, interview requests, in-out register, and an automated release diary generator. It will allow police officials, data managers, and administrators to manage prisoner data and generate various reports. The system is intended to effectively manage prisons through the collection and organization of prisoner information and records.
Copyright:
Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online from Scribd
<place your TAs name here> <place the date of submission here>
Software Requirements Specification for <Project>
Page 2
Contents 1 INTRODUCTION...........................................................................................................................................................3 1.1 DOCUMENT PURPOSE ............................................................................................................................................3 1.2 PRODUCT SCOPE...................................................................................................................................................3 1.3 INTENDED AUDIENCE AND DOCUMENT OVERVIEW.......................................................................................................3 1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS...........................................................................................................3 1.5 DOCUMENT CONVENTIONS......................................................................................................................................3 1.6 REFERENCES AND ACKNOWLEDGMENTS......................................................................................................................4 2 OVERALL DESCRIPTION...........................................................................................................................................5 2.1 PRODUCT PERSPECTIVE...........................................................................................................................................5 2.2 PRODUCT FUNCTIONALITY ......................................................................................................................................5 2.3 USERS AND CHARACTERISTICS .................................................................................................................................5 2.4 OPERATING ENVIRONMENT......................................................................................................................................6 2.5 DESIGN AND IMPLEMENTATION CONSTRAINTS.............................................................................................................6 2.6 ASSUMPTIONS AND DEPENDENCIES............................................................................................................................6 3 SPECIFIC REQUIREMENTS.......................................................................................................................................7 3.1 EXTERNAL INTERFACE REQUIREMENTS......................................................................................................................7 3.2 FUNCTIONAL REQUIREMENTS...................................................................................................................................7 3.3 BEHAVIOUR REQUIREMENTS....................................................................................................................................7 4 OTHER NON-FUNCTIONAL REQUIREMENTS....................................................................................................8 4.1 PERFORMANCE REQUIREMENTS................................................................................................................................8 4.2 SAFETY AND SECURITY REQUIREMENTS.....................................................................................................................8 4.3 USER INTERFACE PRIORITIES AND SOFTWARE QUALITY ATTRIBUTES ...............................................................................8 4.4 OPTIONAL FEATURES ............................................................................................................................................9
Revisions Version Draft Type and Number Primary Author(s) Full Name Description of Version Information about the revision. This table does not need to be filled in whenever a document is touched, only when the version is being upgraded. Date Completed 00/00/00
Software Requirements Specification for <Project>
Page 3
1 Introduction 1.1 Document Purpose This project is aimed at developing a prison management system that 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.2 Product 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. 7.The system should have an interface for the Data Managers for the data updation. 8.The system should have an interface for Police officials with read only access.
1.3 Intended Audience and Document Overview
The management system is intended for : 1. Police officials 2. Data Manager 3. Administrators
1.4 Definitions, Acronyms and Abbreviations
1. UML: Unified Modelling Language 2. 3. 4. 5. 6. 7. 8. 7. J2EE: Java 2 Platform Enterprise Edition XML: Extended Markup Language AJAX: Asynchronous JavaScript and XML HTML: Hyper Text Markup Language SOA: Service Oriented Architecture HTTPS: Hyper Text Transfer Protocol Secure SRS: Software Requirement Specification JSP: Java Server Pages
2 Overall Description 2.1 Product Perspective This product is <Describe the context and origin of the product being specified in this SRS. For example, state whether this product is a follow-on member of a product family, a replacement for certain existing systems, or a new, self-contained product. If the SRS defines a component of a larger system, relate the requirements of the larger system to the functionality of this software and identify interfaces between the two. In this part, make sure to include a simple diagram that shows the major components of the overall system, subsystem interconnections, and external interface. In this section it is crucial that you will be creative and provide as much information as possible. TO DO: Provide at least one paragraph describing product perspective. Provide a general diagram that will illustrate how your product interacts with the environment and in what context it is being used.>
2.2 Product Functionality
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. Case register: All the details of the cases against the prisoner should be captured. This must include the sentence details, remand/conviction details, etc. 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. Parole register: This module should track all prisoners on parole and provide necessary reports on this data. Duty register: Who was where, why and when. Interview requests: All interview requests by the relatives of the prisoners need to be recorded and tracked. In-out register: 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. Fund allotted and routine accounting transactions should be captured.. Basic and advance admin facilities like add/update users, backup/recovery of data, generating various reports etc.
2.3 Users and Characteristics
A. Police officers (Read only access) B. Data Manager (Can add/update data) C. Administrators (Jail admin/government officials)
Software Requirements Specification for <Project>
Page 6
2.4 Operating Environment
Linux (preferable)
2.5 Design and Implementation Constraints
Design Constraint : Website should be highly customizable and flexible enough to easily deploy without much effort. Implementation Constraint:
2.6 Assumptions and Dependencies
<List any assumed factors (as opposed to known facts) that could affect the requirements stated in the SRS. These could include third-party or commercial components that you plan to use, issues around the development or operating environment, or constraints. The project could be affected if these assumptions are incorrect, are not shared, or change. Also identify any dependencies the project has on external factors, such as software components that you intend to reuse from another project. TO DO: Provide a short list of some major assumptions that might significantly affect your design. For example, you can assume that your client will have 1, 2 or at most 50 Automated Banking Machines. Every number has a significant effect on the design of your system. >
Software Requirements Specification for <Project>
Page 7
3 Specific Requirements 3.1 External Interface Requirements 3.1.1 User Interfaces Client on Internet: Web Browser, Client on Intranet: Client Software, Web Browser,
Client on Internet: Web Browser, Client on Intranet: Client Software, Web Browser, Web Server: Apache Tomcat Data Base Server: MySQL,
3.1.4 Communications Interfaces
Network Server communication protocol
3.2 Functional Requirements
1. Nominal Roll 2. Case Register 3. Automated Release Diary Generator 4. Parole Register 5. Duty Register 6. Interview Requests 7. In-out Register 8. Fund Allotment and Routine Accounting transaction 9. Admin Facilities .
3.3 Behaviour Requirements
3.3.1 Use Case View <A use case defines a goal-oriented set of interactions between external actors and the system under consideration. Since sometimes we will not be able to specify completely the behaviour of the system by just State Diagrams, we use use-cases to complete what we have already started in section 3.3.1.
Software Requirements Specification for <Project>
Page 8
TO DO: Provide a use case diagram which will encapsulate the entire system and all possible actors. Do not include detailed use case descriptions (these will be needed when you will be working on the Test Plan), but make sure to include a short description of what every use-case is, who are the actors in your diagram. For more information please refer to your UML guide and the MiniThermostat SRS example file.>
4 Other Non-functional Requirements
4.1 Performance Requirements 1. 24 X 7 availability 2. Better component design to get better performance at peak time 3. Flexible service based architecture will be highly desirable for Future extension 4. For Secure access of confidential data, SSL can be used
4.2 Safety and Security Requirements
1. Secure Access of confidential data 2. Two kinds of authentication required. One for jailers and police officials Other for data mangers and admin. 3. The system can be SSL security certified.
4.3 User Interface Priorities and Software Quality Attributes
1. 2. 3. 4. 5. Professional look and feel Use of AJAX atleast with all registration forms Browser testing and support for IE, NN, Mozilla Firefox. Use of Graphical tool like JASPER to show strategic data to admin Reports exportable in .XLS, .PDF or any other desirable format
Software Requirements Specification for <Project>
Page 9
4.4 Optional Features
1. Java based client for User B & C 2. Customizable color scheme or skins 3. Help-pages of the application in the form of Q&A
