System Requirement Specification

Transcription

1 Fair Hearing Resource Center System Requirement Specification State University of New York at Buffalo Team 20 (Amit Shrikant Kulkarni) (Chirag Todarka) (Satish Saley) (Uday Deep Singh)

2 Table of Contents Table of Contents... 1 Table Of Figures Assumptions Limitations Functional Requirements Software Architecture Block Diagram Data Flow Diagram User Interfaces/ Web page Administrative Panel User Screen Change Request Form Cross Level Referencing Table Of Figures Figure 1: Software Architecture Block Diagram... 4 Figure 2: Data Flow Diagram... 7 Figure 3: Design of Admin Panel... 8 Figure 4: Design of Search Page

3 1. Assumptions The assumptions made by the development team are as follows: 1.1. The archived decisions on OTDA website will be in PDF and fixed data format. Any change in this assumption would require changes in the Data Extraction logic It has been assumed low income applicants applying for Fair Hearing, have internet access We always have full access to the OTDA database without any authentication; otherwise system cannot update the new cases Over the period of time as data grows, the Client will add new servers to the system. 2

4 2. Limitations 2.1. The verification process for expert users (e.g. Attorneys) is not automated. The administrator needs to individually verify and approve each request For important cases the case summary will be added by expert community. This process can be automated in future Currently the system is implemented only for New York State clientele. It can be further extended for other states in future The content of the discussion forum cannot be monitored automatically. The administrator needs to delete offensive content manually from the website. 3

5 3. Functional Requirements 3.1. Software Architecture Block Diagram Figure 1: Software Architecture Block Diagram OTDA Decision Archive The OTDA Fair Hearing Decision Archive will be the source for the Fair Hearing database Data Extraction, Insertion and Sanitization (DEIS) Unit The Data Extraction module gets initiated when a fair hearing case is uploaded onto the database. It is responsible for the following: Capturing keywords from PDFs and noting crucial information about each case. This specific information would be used for categorization and indexing of the 4

6 topics, attributes and metadata. Some examples of such picked up data can be the age of the applicant when the case was heard, the laws referenced in a particular hearing, final decision etc. Most of the data aggregated above shall also serve as an initial template for the case outline (digest). Ensuring that the information is redacted and no possible sensitive information is stored. The most common categories in fair hearing PDF files, the data that can be picked form them and their use is explained below. (An example PDF is located here Jurisdiction: The County location and Fair Hearing Representative can be saved and used for categorization. Issue: The two parties (if available) and the dispute can be stored. The dispute can be used to search for cases particular to an area of law. Findings of Fact: The evidences and previous historical events can be saved. This is especially useful since it can provide pointers to Attorneys to where to look for case winning information in new future cases. Most of these facts are applicable to most cases in a particular area, hence can be suggested in the search within in a particular area of law. Applicable Law: The list of all the laws that were used in the case can be saved. This list suggests different perspectives of the case and tools that can be used by attorneys when dealing with similar cases. Discussion: Any special notes by the judge (if any) can be saved. Decision Order: The decision can be saved and used to filter cases by result when searching. All information selected above shall be stored as a link to the FH# (Fair Hearing number) of the case Fair Hearing Database The results after DEIS unit is inserted into Relational Database for indexing and searching. The database will also store the online discussions, site configuration settings and User profiles. All the server applications fetch data from the database for processing and displaying. 5

7 Search Engine: The search engine module will work by combining the results of a full text search on the PDF files and applying the selected filters on the results. The flow shall be: Real Time PDF Search: The PDF files shall be searched for the search keywords and all matching files shall be ordered on the basis of the occurrence of the keyword. The occurrence shall be contextual though i.e. the spread of the keyword over the document shall also contribute equally to the occurrence count. Application of Filter: The selected filters (e.g. year range, won-lost etc.) shall be applied onto the list generated above. The information that was collected by the Data Extraction, Insertion and Sanitization Unit shall be mapped to the current list and relevant information shall be displayed Case Viewer: The case viewer is a frontend module that shall display a particular fair hearing case. The view shall contain information saved by the Data Extraction, Insertion and Sanitization Unit and the full PDF file. It shall also show similar cases as this cases DEAS information. Below each case shall be its associated discussion Discussion Board Application: This will power the discussions between Attorneys on each case. It will be moderated by the administrators and not visible to common users User Management: This module will facilitate user logon, new user registration and authentication. Also for every new user, a verification will be sent to the user s ID which will allow only real users to be able to register. This module will also maintain different permission levels for common users and attorneys, and allow a common user to request to be promoted to an attorney level. Other common features will be Change password and Forgot password Site Configuration: This module powers the admin panel and will allow the administrators to maintain the newsletter subscriptions, promote a common user to an Attorney/Administrator level (and vice-versa) and manage the database contents. 6

8 3.2. Data Flow Diagram Figure 2: Data Flow Diagram 7

9 4. User Interfaces/ Web page 4.1. Administrative Panel An administrative panel will help administrators to approve users, change their access levels, and moderate the discussion forum. Figure 3: Design of Admin Panel 8

10 4.2. User Screen Search facility will help any registered user to browse through decisions. User can apply filters provided to obtain more accurate results. Forum tab will be availabe to users who are atttorneys. Figure 4: Design of Search Page 9

11 5. Change Request Form The customer can use following form to change current system specifications. 10

12 Fair Hearing Resource Center Change Request Form Change Request # Name of Submitter Type of Change Request [ ]Enhancement [ ]Defect [ ]Other Severity [ ]High [ ]Normal [ ]Low Description Brief Description of Change Reason for Change Comments Any attachments or references? Signature [ ]Yes [ ]No Date Manger Approval Number of hours required Cost Impact Comments Signature Date Change Request Approval Committee Approved [ ]Yes [ ]No Comments Signature Date 11

13 6. Cross Level Referencing The following table provides list of Functional Requirements and cross reference to description of each specification. The table can be used as task list or project control list in future iterations of development. Sr. No. Functional Requirements References 1. Relevant Search Results Sections 3.1.2, 3.1.3, 3.1.4, Outline (Digest) Section Discussion Forum Section Registration Process Section Different User Access Levels Section Highlight the Case Importance Section Comments Section Section

14 Fair Hearing Resource Center Integration Thread Design 13

15 Part B : Integration Thread Design Figure 1: Integration Thread Design The modules for the Integration Thread (Base version) would be: Fair Hearing Database User Management System + Register + Log In Site Configuration + Admin Panel Search Engine (Simple, text based) + Search page + View Case Since providing the relevant search results is the main driving force behind the initialization of this project, this is the main requirement of the project and should be implemented first. All the 14

16 other system functionalities (e.g. digest: 3.1.4, discussion forums : 3.1.6) revolve around the search capabilities. The building blocks of the Search Engine are: Query Formulation Data Representation Data Storage Search Algorithm Result Representation (The details of search engine design are given in Search Engine Requirements and Search Engine Deployment) The designed integration thread completes the task of data representation in a relational database by storing data as simple PDFs. The initial algorithm will be implemented based on pattern matching the keywords entered by the user. The query formulation would be done on the search page. The initial search page would consist of only 2 sections: a field to enter search terms, and search button. The results will be returned on the same page below the search filed. Along with the implementation of this core module, essential features of the User & Configuration Management module such as Registration and Authentication process will also be implemented. This way the Integration thread will allow user to login to the Resource Center and Search the database for relevant information specifying keywords. The user feedback would be used in future interactions for enhancement and tuning of search results along with addition of new features in the project. 15