Upload
trananh
View
265
Download
3
Embed Size (px)
Citation preview
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)
System Requirement Specification 1
Table of Contents
Table of Contents ................................................................................................ 1
Table Of Figures .................................................................................................. 1
1. Assumptions ................................................................................................. 2
2. Limitations .................................................................................................... 3
3. Functional Requirements .............................................................................. 4
3.1. Software Architecture Block Diagram ..................................................... 4
3.2. Data Flow Diagram .................................................................................. 7
4. User Interfaces/ Web page ........................................................................... 8
4.1. Administrative Panel ............................................................................... 8
4.2. User Screen ............................................................................................. 9
5. Change Request Form ................................................................................. 10
6. Cross Level Referencing .............................................................................. 12
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 ........................................................................... 9
System Requirement Specification 2
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.
1.2. It has been assumed low income applicants applying for Fair Hearing, have internet
access.
1.3. We always have full access to the OTDA database without any authentication;
otherwise system cannot update the new cases.
1.4. Over the period of time as data grows, the Client will add new servers to the system.
System Requirement Specification 3
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.
2.2. For important cases the case summary will be added by expert community. This
process can be automated in future.
2.3. Currently the system is implemented only for New York State clientele. It can be further
extended for other states in future.
2.4. The content of the discussion forum cannot be monitored automatically. The
administrator needs to delete offensive content manually from the website.
System Requirement Specification 4
3. Functional Requirements
3.1. Software Architecture Block Diagram
Figure 1: Software Architecture Block Diagram
3.1.1. OTDA Decision Archive
The OTDA Fair Hearing Decision Archive will be the source for the Fair Hearing
database.
3.1.2. 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
System Requirement Specification 5
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
http://www.otda.ny.gov/fair%20hearing%20images/2012-
11/Redacted_6153968Y.pdf)
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.
3.1.3. 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.
System Requirement Specification 6
3.1.4. 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.
3.1.5. 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.
3.1.6. 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.
3.1.7. User Management: This module will facilitate user logon, new user registration
and authentication. Also for every new user, a verification email will be sent to the
user’s email 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.
3.1.8. 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.
System Requirement Specification 8
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
System Requirement Specification 9
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
System Requirement Specification 10
5. Change Request Form
The customer can use following form to change current system specifications.
System Requirement Specification 11
Description
Manger Approval
Change Request Approval Committee
Fair Hearing Resource Center Change Request Form
Change Request #
Name of Submitter
Type of Change Request [ ]Enhancement [ ]Defect [ ]Other
Severity [ ]High [ ]Normal [ ]Low
Brief Description of Change
Reason for Change
Comments
Any attachments or references?
[ ]Yes [ ]No
Signature
Date
Number of hours required
Cost Impact
Comments
Signature
Date
Approved [ ]Yes [ ]No Comments
Signature
Date
System Requirement Specification 12
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, 3.1.5
2. Outline (Digest) Section 3.1.2
3. Discussion Forum Section 3.1.6
4. Registration Process Section 3.1.7
5. Different User Access Levels Section 3.1.8
6. Highlight the Case Importance Section 3.1.4
7. Comments Section Section 3.1.6
System Requirement Specification 14
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
System Requirement Specification 15
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.