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 7

3.2. Data Flow Diagram

Figure 2: Data Flow Diagram

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 13

Fair Hearing Resource Center

Integration Thread

Design

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.