Scenario: Law Office Management System / Law (Legal) Practice Management System

Transcription

1 Scenario: Law Office Management System / Law (Legal) Practice Management System Software is to be developed for Law Office Management / Law Practice Management using which people can find lawyer s on the internet. There may be the lawyers or the clients who have their cases registered in the court. This website provides facility for the lawyers to have all its previous details of all the registered cases stored in the database along with the details of the next judgment day for that particular case. Hence, at the time of referring the case again, he can check the previous details and can also plan for the future judgment. This application would be having four types of accessibilities. They are: Admin accessibility, Lawyer side accessibility, Client side accessibility, User accessibility. Admin Accessibility: An Admin in this project can make the entries of the lawyers who register with the website. Only after a lawyer is registered by the admin, he can further carry out his tasks with his clients. For the first time a lawyer registers himself, he gets an id and password which he uses throughout the time. Lawyer side accessibility: A Lawyer can register his clients and can store all the case details of his clients in the database. He has the previous details of the case which can help him plan for the further evaluation of the case. Also the cases that have been completed accidentally (due to withdrawal, death, etc), or those have been solved by him are stored in the database which he can use as a reference for the future cases. Client side accessibility: A client can see his case details and all the transactions carried out during the case. He can also find out new lawyers through this website. User/Visitor accessibility: New visitors can also visit this site and find lawyers online by viewing the details of the lawyers available in the website and selecting the one best suited for them. They can do this by simply entering their valid name and ids. Every time a non-member logs in, he has to enter his name and id in a valid format. They do not need to pay anything for this. Design SRS, Use Case Diagrams, DFDs, CFDs, ER Diagrams, Activity Diagrams, State Diagrams, Sequence Diagrams, Class Diagrams and Data Dictionary for this scenario. Radhika N. Kotecha Page 1

2 Software Requirement Specification Law Practice Management System Radhika N. Kotecha Version: 1.0 Radhika N. Kotecha Page 2

3 1. Introduction This section describes the purpose, scope and an overview of the entire system. 1.1 Purpose: The current scenario used by the lawyers in maintaining heavy file works for keeping the records of their cases. Online Law Practice Management System is a new website for people to find lawyers via use of internet and also for the lawyers and clients to maintain a record of the cases they are dealing with. Now a day, court cases are out merging everywhere. A lot of people need to contact their lawyers regularly or find appropriate lawyers for their cases. The goal of the project is to provide a flexible way to the people to fulfill their requirements. The admin of the website can register different Lawyers and each lawyer can in turn register his/clients. The lawyers and clients can work out with their cases. This site provides a flexible way for lawyers and clients to handle their cases in a well-formatted way online through any part of the world. Also, new users can find lawyers online according to their needs. 1.2 Scope: In-Scope: Scope of this application is limited in a way that only the admin can register lawyers for this website and only lawyers can register their clients. Further, the lawyer can maintain details of his client s cases. Clients who are registered by the lawyer can view their case details as entered and managed by the lawyer. Using this website, non-member users can also find profiles of different lawyers registered with this website. Out-of-Scope: Registration of a lawyer by himself or registration of a client by himself is out of scope of this system. Making payments to lawyers by the clients is also out of scope of the system. 1.3 Overview: The rest of this SRS is organized as follows: Section 2 gives an overall description of the software. It gives what level of proficiency is expected of the user, who will be using the system, some assumptions and dependencies of the system. Section 3 gives specific functional requirements which the software is expected to deliver. Section 4 describes the interface requirements whereas Non-functional requirements are listed in Section 5. The costing of the software is given in Section 6. The definitions, acronyms, and abbreviations and the user screens are given in section 7. Radhika N. Kotecha Page 3

4 2. General Description This section describes the product perspective, user characteristics, principal actors and the assumptions and dependencies of the system. 2.1 Product Perspective: LPMS is aimed towards finding lawyers via use of internet and also for the lawyers and clients to maintain a record of the cases they are dealing with. LPMS should be user-friendly and quick to learn so that all the clients can use it. 2.2 Principal Actors: The website has 4 principal actors: 1. Admin 2. Lawyer 3. Client 4. Visitor 2.3 User Characteristics: The admin must be having hands-on knowledge of the computer as he has to manage the entire website. He can either be the developer of the website or an authority who has hired a software developer to maintain the website on his behalf. The person using the website as a lawyer must be a computer literate and a member of the website. Also, he should be a qualified lawyer. The clients should also be computer literate and should be having their cases submitted to at least one of the lawyers registered with the system. 2.4 Assumptions and Dependencies: Full working of LPMS is dependent on the availability of Internet connection. The details of the client s cases are as entered by the lawyer and gets updated only when the lawyer updates it. It is assumed that all the case-transaction related contents posted by the lawyers is true, however, the software is a stand-alone website managed by the admin and registered lawyers. No part of the website is dependent on or is concerned with the websites of any court. Only the lawyers shall be responsible for the contents they have posted. It is also assumed that all the lawyers who want to register with this website contact the admin and provide the proof of their identity, all outside the scope of the software. Further, it is assumed that that the clients have registered themselves to the lawyers out of the club. It is also assumed that payment is done explicitly. Radhika N. Kotecha Page 4

5 3. Functional Requirements This section describes different functional requirements of the system in terms of the functions/features the system should provide. 1. Login for Admin (by Admin) 2. Registration of Lawyer (by Admin) 3. Update details of Lawyers (by Admin) 4. Delete Lawyer (by Admin) 5. Login for Lawyer (by Lawyer) 6. Registration of Clients (by Lawyer) 7. Update details of Clients (by Lawyer) 8. Delete Client (by Lawyer) 9. Add case details of Clients (by Lawyer) 10. Update case details of Clients (by Lawyer) 11. Delete Cases of Clients (by Lawyer) 12. Login for Client (by Client) 13. View/ Download Case Details (by Client) 14. Registration as Visitor of Website (by Any New User) 15. Finding Lawyers (by a registered Visitor) After being logged in, an admin in this project can make the entries of the lawyers who register with the website, can update details of lawyers or delete a lawyer. Only after a lawyer is registered by the admin, he can further carry out his tasks with his clients. For the first time a lawyer registers himself, he gets an id and password from the admin which he uses throughout the time. After being logged in, a lawyer can register his clients, update client s details, delete a client and can store all the case details of his clients in the database. He has the previous details of the case which can help him plan for the further evaluation of the case. Also the cases that have been completed accidentally (due to withdrawal, death, etc), or those have been solved by him are stored in the database which he can use as a reference for the future cases. A lawyer can also update the case details of his clients and can also delete some cases if desired. After being logged in, a client can see his case details and all the transactions carried out during the case. He can also find out new lawyers through this website. New visitors can also visit this site and find lawyers online by viewing the details of the lawyers available in the website and selecting the one best suited for them. They can do this by simply entering their valid name and ids (i.e. by registering themselves). Every time a non-member logs in, he has to enter his name and id in a valid format. They do not need to pay anything for this. By default, a list of all the lawyers registered with the website appears. Radhika N. Kotecha Page 5

6 Out of these lawyers, specific lawyers can be searched based on the city of lawyers or by searching based on their names and photographs. 4. Interface Requirements This section describes different interface requirements of the system: 4.1 Hardware Interface Requirements: Wireless Ethernet Card for internet connectivity. 4.2 Software Interface Requirements: Web Browser such as Internet Explorer 7.0 or later, Mozilla Firefox or any browser. 4.3 External Interface Requirement (GUI Requirements): One way to search lawyers can be by selecting a city and getting list of all the lawyers available in that city. Court-type can also be mentioned with this. Other way is where photographs along with the names of all the available Lawyers should appear while any user searches for lawyers. More information about a lawyer can be obtained by clicking his/her photograph. Appendix shows the intended user screen. 5. Non-Functional Requirements The non- functional requirements of the system are as follow: 4.1 Performance Requirements: 90% of the responses should be within 2 sec, except for downloading the entire case history for which more time is acceptable. 4.2 Security: Data containing information regarding client s case should be secured against malicious deformations. 4.3 Reliability/Fault Tolerance: Data should not become corrupted in case of system crash or power failure. 4.4 Maintainability: The system should be having high maintainability in terms of correctness, adding new functionalities and should be highly adaptive. Radhika N. Kotecha Page 6

7 NOTE: You can add other non-functional requirements. A list of some common nonfunctional requirements with their meanings is as follow: 1. Security Confidentiality extent to which data and processes are protected from unauthorized disclosure Integrity extent to which data and processes are protected from unauthorized modification Availability extent to which data and processes are protected from denial of service to authorized users, its 24x7 availability if hosted on WWW 2. Reliability Non-deficiency degree to which application does not contain undetected defects Fault tolerance degree to which software will continue to work without system failure that would cause damage to users data 3. Maintainability Corrective - finding and fixing faults Adaptive Modifying Software for a changed environment. New functionality is added, rewrite documentation or comments, renaming a variable or routine 4. Portability Hardware Independence degree to which application does not depend on specific HW requirements Software Independence degree to which application does not depend on specific SW environments 5. Reusability Generality extent to which application can be reused across applications Self Descriptiveness ease with which a application component can be understood and used Radhika N. Kotecha Page 7

8 6. Costing The whole system with all other supporting components can be packaged and easily deployed to server. The system uses Microsoft SQL Server Express edition, which comes for FREE from Microsoft. The system does not need any exclusive packaging or any other amenities. So the cost of the application can be really very low while providing so many great features. It costs for web space where it is being to deploy as well as for the domain name which it requires. 7. Appendices 7.1 Acronyms and Abbreviations: LPMS: Law Practice Management System. SRS: Software Requirements Specification. WWW: World Wide Web. GUI: Graphical User Interface. 7.2 Definitions: Case Transaction: A case transaction consists of data/results of the court hearing corresponding to a date of hearing along with a sequence number per hearing. Interface Design/User Screens: The diagrams below show the outline of the main user screens. Figure 1: Admin Login Form Radhika N. Kotecha Page 8

9 Figure 2: New Member Creation Page Figure 3: Modify Lawyer Detail Page Radhika N. Kotecha Page 9

10 Figure 4: User Login Page Figure 5: Page for finding a Lawyer Radhika N. Kotecha Page 10

11 Figure 6: New Client Entry Form Figure 7: Client Case Detail Form Radhika N. Kotecha Page 11

12 List of Tables: Table Name Table Description tbl_admin This table stores the username and passwords of administrators. tbl_lawyer_master This table stores the whole detail of lawyer with username and password. tbl_client_master This table stores the detail of client with username and password. tbl_case_master This table stores the name, id and type of the case which is uploaded by the lawyer. tbl_case_transaction This table stores the detail of the case and also stores the status of it. tbl_user_master This table stores the information about the visitor of the website. tbl_admin:- Attribute Datatype Constraint UserName Password varchar(15) varchar(15) tbl_lawyer_master:- Attribute Datatype Constraint L_Id Int Primary Key L_Name varchar(30) Not Null L_Quali varchar(30) Not Null L_Type varchar(10) Not Null L_Address varchar(200) L_City varchar(30) Not Null L_ _ID varchar(50) Not Null L_Photo image L_Mobile_No varchar(15) L_Court_Type varchar(20) L_Lic_No varchar(30) Not Null L_Assoc_Member char(1) Default N L_Exp varchar(20) User_Name varchar(20) Not Null Password varchar(20) Not Null Radhika N. Kotecha Page 12

13 tbl_client_master:- Attribute Datatype Constraint L_Id Int Foreign Key references Lawyer Master C_Id Int Primary Key C_Name varchar(30) Not Null C_Address varchar(200) C_City varchar(30) Not Null C_ varchar(50) Not Null C_Contact_No varchar(15) Not Null C_Gender char(1) M or F C_Age char(1) User_Name varchar(10) Not Null Password varchar(10) Not Null tbl_case_master:- Attribute Datatype Constraint Case_Id int Primary Key L_Id int Foreign Key references Lawyer Master C_Id int Foreign Key references Client Master C_Type varchar(10) Not Null C_Name varchar(50) Not Null C_OPP_Name varchar(50) Not Null C_Detail varchar(max) C_St_Date datetime Not Null C_Status varchar(20) Not Null Radhika N. Kotecha Page 13

14 tbl_case_transaction:- Attribute Datatype Constraint Case_Id Int Foreign Key references Case Master Case_Date Datetime Not Null Case_Detail varchar(max) Case_Reason varchar(100) Case_Status varchar(20) tbl_user_master:- Attribute Datatype Constraint User_Id Int Primary Key Name varchar(50) Not Null varchar(50) Not Null Login_Date datetime Auto Generated Use Case Diagrams: Figure: Use Case Diagram for Admin Radhika N. Kotecha Page 14

15 Figure: Use Case Diagram for Lawyer Figure: Use Case Diagram for Client Radhika N. Kotecha Page 15

16 Data Flow Diagrams Figure: Use Case Diagram for Visitor Admin Login Details User Name, Pwd Lawyer Lawyer Details Name, ID Law Practice Management System Login Details Client Details Case Details Login Details Visitor Lawyer Details Case Details Client Figure: Context Diagram (DFD Level 0) Radhika N. Kotecha Page 16

17 Figure: Level 1 Data Flow Diagram Figure: Level 2 Data Flow Diagram Radhika N. Kotecha Page 17

18 Activity Diagram Figure: Activity Diagram Radhika N. Kotecha Page 18

19 ER Diagram Figure: ER Diagram Radhika N. Kotecha, M.Tech. (ICT), Pursuing Ph.D. Nirma University, Asst. Prof., V.V.P. Engineering College, Rajkot. Radhika N. Kotecha Page 19