EVARS_functionalrequirements_V10_04142011.docx

7.0 Security

Attachment 5

FUNCTIONAL

REQUIREMENTS

DOCUMENT

Extensions and Variances Automated Requests System (EVARS)

U.S. Department of Housing and Urban Development

April 2011

Revision Sheet

Revision Sheet

Functional Requirements Document Page ii

Functional Requirements Document Authorization Memorandum

I have carefully assessed the Functional Requirements Document for the Extensions and Variances Automated Requests System (EVARS). This document has been completed in accordance with the requirements of the HUD System Development Methodology.

MANAGEMENT CERTIFICATION - Please check the appropriate statement.

______ The document is accepted.

______ The document is accepted pending the changes noted.

______ The document is not accepted.

We fully accept the changes as needed improvements and authorize initiation of work to proceed. Based on our authority and judgment, the continued operation of this system is authorized.

United States Department of Housing and Urban Development

Government Technical Representative

Director

C&L Service Corporation

For C&L Service Corporation

FUNCTIONAL REQUIREMENTS DOCUMENT

TABLE OF CONTENTS

Page #

Functional Requirements Document Page iv

1.0 GENERAL INFORMATION

1.0 General Information

Functional Requirements Document

GENERAL INFORMATION

1.1 Purpose

The Functional Requirements Document (FRD) defines the functional requirements for a web-based automated system for the extensions and variances process.

1.2 Scope

The Extensions and Variances Automated Requests System (EVARS) will automate the current manual process of reviewing, approving, and denying extensions for initiation of foreclosure by servicing lenders and requests for variances.

The extensions apply to HUD’s Insured Title II and HECM Insured loan programs which provide specific time frames for initiation of foreclosure by servicing lenders. When circumstances prevent initiating foreclosure by those deadlines, servicing lenders may request an extension, which avoids curtailment of their debenture interest on future claims. A lender must complete form HUD-50012 Mortgagee’s Request for Extensions of Time to request an extension.

The variances program allows lenders to request for a variance when guidelines may otherwise prohibit the use of loss mitigation tools. The lenders must complete form HUD-90041 Request for Variance.

These two forms – HUD-50012 Mortgagee’s Request for Extensions of Time and HUD-90041 Request for Variance will be automated by developing a web-based application that lenders will access via the World Wide Web to complete and submit the forms to HUD for extensions and variances.

The EVARS shall provide the capability to:

1.

1.1.

1.2.

1.2.1. Access to the FHA Connection portal. The FHA Connection provides FHA-approved lenders and business partners with direct, secure, online access to computer systems of the U.S. Department of Housing and Urban Development (HUD). FHA-approved lenders use the FHA Connection for originating and servicing FHA-insured single family home mortgages and updating their lender information. It is expected that the FHA Connection will filter inquiries and only permit authorized mortgagees access to the system. The entry into the system will constitute validation and signature for any required forms. The HUD-50012 will be accessed electronically while online, and CLS will provide the means for the user to complete and submit the required form electronically. It is anticipated that this will be a two step process. The information on the top portion of the form – Mortgagee’s Name and Address, Mortgagor’s Name and Property Address, Mortgage Loan Number, and FHA Case Number – will be automatically verified with the data from Single Family Insurance System (SFIS). Should there be any discrepancies between the information in SFIS and that submitted by the Mortgage, the program will request clarification and not accept the request. These items would include incorrect mortgagee, incorrect mortgagor, failure of case number and address to agree, and other similar items.

1.2.2. Provide validation that all required input fields in the forms are complete and accurate. Validation shall be performed before form submittal. Validation shall include the internal logic of the request; for example, if checking a particular item but the required information is not provided on the input field, HUD designed business rules shall be applied to the submitted information and shall be used to approve or deny the request.

1.2.3. Approved requests are forwarded to HUD for approval and signature based on HUD’s business rules. HUD shall release, sign, and fax the forms to the appropriate party. The approved form will be referred to an employee and managed under Phase III. Information about the requests will be posted to the mortgagee’s inbox.

1.2.4. Require that certain information be imaged and tied with the application for forms not approved. The provision for imaging the information and tying it to the form must be programmed at this time.

1.2.5. Provide printing access to lenders for a period of 18 months after submission for forms that are accepted by HUD. During this period, they shall be able to print the form at any time.

1.2.6. Track rejected requests for extensions to determine the reason for rejection, which shall be used by HUD to determine training needs.

1.2.7. Track how often an extension request is made on a particular loan and shall flag that loan for follow-up after a second submission.

1.2.8. Develop and prepare management reports in accordance with HUD’s requests to monitor rejected extensions. These reports shall be accessible to HUD designated users and if desired, by the individual lender.

1.2.9. Have reports and all forms submitted kept available for 18 months after submission.

1.2.10. Prepare and have accessible a manual that explains how to perform various actions.

1.2.11. Create a variance log with HUD defined parameters. This log will be able to provide reports.

1.3 Project References

References

EVARS Functional Requirements Document

EVARS Technical Proposal

HUD Standard Procedures Documents

1.4 Acronyms and Abbreviations

1.5 Points of Contact

1.5.1 Information

1.5.2 Coordination

1.0 General Information

Functional Requirements Document Page 1-3

2.0 CURRENT SYSTEM SUMMARY

2.0 Current System Summary

Functional Requirements Document

Current SYSTEM SUMMARY

2.1 Background

The current process for reviewing, approving, or denying extensions and variances is completely manual.

2.2 System Objectives and Current Functionality

There is no automated system that is currently implemented.

2.3 Current Methods and Procedures

The current methods for handling extensions and variances include the use of the HUD-50012 and HUD-90041 forms which are submitted via mail or fax and checked against established business rules and guidelines. Requests for extensions and variances are tracked and manually entered in a spreadsheet.

2.3.1 Equipment Being Used

PC, Workstation or Laptop equipped with a spreadsheet program.

2.3.2 Input and Output

Process is completely manual.

2.3.3 Provisions in the Existing System Design

None

2.3.4 Deficiencies

2.0 Current System Summary

The current method and procedures for reviewing, approving, and tracking extensions and variances is time consuming and prone to errors. Lenders are required to manually fill out forms and mail or fax them to HUD. The flexibility of real-time requests for extensions and variances is lacking. The manual approach is limited in tracking lenders requests and is prone to human errors. Data and information can easily be tampered with and modified. There are no security measures in protecting the integrity of the data in the spreadsheets.

Functional Requirements Document Page 2-1

3.0 PROPOSED METHODS AND PROCEDURES

3.0 Proposed Methods And Procedures

Functional Requirements Document

Proposed Methods and Procedures

The proposed methods and procedures for the EVARS will provide web-based, real-time access to lenders for requests of extensions of time and variances. Lenders shall have the ability to fill out forms HUD-50012 Mortgagee’s Request for Extensions of Time and HUD-90041 Request for Variance. In the interim, HUD shall provide a monthly data dump of the SFIS data. The data shall be loaded into the EVARS database as a reference table from which to verify lenders’ information and populate required form fields of the system. Another data dump containing lenders’ information shall be provided by HUD and refreshed every six months.

The system shall verify and validate lenders’ FHA Case Number against the Single Family Insurance System (SFIS) data for the FHA loan types. For the HECM loans, a monthly data dump from the SMART system shall be provided. The data shall be loaded into the EVARS database as a reference table for verifying users’ information when requesting extension of time on HECM loans. Should there be any discrepancies between the information entered by a lender in the EVARS and the reference tables, clarification and additional information shall be requested and the request shall not be accepted by EVARS. In addition to the FHA Case Number, all required input fields shall be validated before forms can be submitted.

The system shall approve and forward requests to HUD for final review, approval and signature. The approved form shall be posted to the mortgagee’s inbox. Information on accepted forms shall be accessible in the system for viewing and printing by the lender for a period of 18 months after submission.

Forms not approved by the system shall be forwarded to an employee and shall have certain information imaged and tied to the application. Information about the denied request shall be posted to a mortgagee’s inbox. Rejected requests for extensions shall be tracked to determine the reasons for rejections and shall be used to determine training needs.

A valid 5-digit lender ID must be provided during the registration. The system shall validate the lender ID against the lender reference table in the database.

The system shall have the capability to accept registration from lenders.

The system shall allow up to 130 users to register for a particular lender.

HUD shall inform CLS when a user needs to be deactivated in the system.

Once the limit of 130 is reached for a particular lender, the system shall reject all subsequent registration for that particular lender.

Prior to submission of registration, a user shall agree to User Agreement and Security Agreement disclaimers.

Once the registration is completed, validated, and submitted, an email shall be generated to HUD administrators for approval.

HUD appointed administrators shall have the ability to access the system and approve or deny a registration.

When a request is approved by HUD through the system administrator’s interface, a confirmation message shall be displayed to the administrator that the user has been approved and logon information has been sent to the user.

An email that contains the new user 3-digit code, unique user name and password shall be generated and sent out to the approved user.

The unique 3-digit user code shall be randomly system generated for each approved user. The code shall contain no leading zeros.

Unique user ID shall be system generated and could be a combination of a user’s first and last names, and date of birth.

Password shall be system generated. The password shall be a combination of 8 alphanumeric characters.

User shall be forced to change their password at the first successful logon using their system generated password. During the password change process a user shall be asked to choose from a list of generic security questions and to provide answer to the question chosen.

The question and answer combination shall be used as a security measure if a user forgets their password and requests to have password emailed to them.

The system shall have password changes capability for approved users with valid logons.

The system shall allow users to request for their forgotten password. To request forgotten password, a user must provide a valid email address, user ID and the correct answer to the provided to selected security question during forced password change. If correct information is provided, password shall be emailed to user.

If provided information does not match database entry, user shall be redirected to the registration page and they will have to re-register and get approved by HUD to use the system.

Approved lenders shall logon at the first layer of authentication with their 5- 10 digit lender ID. Once lender ID is authenticated, lender shall be directed to the second layer logon screen where they will be required to provide their 3-digit unique code and combination of the unique user ID and system-generated password for the first time, subsequent logon shall be with the password the user has provided.

If a user enters an invalid Lender ID, they shall have 2 additional tries to enter a valid ID, after the third failed attempt, users shall be displayed a message to the effect” You Lender ID could not be verified. Please call: 1-877-622-8668 to have your account unlocked. Users may also email the support team at support@hudtulsa.org

User Interactions

When a lender inputs a FHA case # into the system, the system validates that the case # is valid or is available to the lender. Since only delinquent case #s are available in EVARS, when a case # is not found, the system shall prompt the user to submit a manual input through the system.

The manual input shall consist of the borrower information, which shall be saved in the database and linked to the lender submitting the information. Once the borrower information is entered and saved, the user shall proceed to request and extension or variance through the normal processing.

The system shall allow lenders to enter subsequent request number if they have submitted an extension/variance previously on the same loan or select Initial Request, if the request is the first on a loan.

The system shall track the number of extensions requests on a particular loan.

An HECM initial request shall go through the business logic and the system will determine if to approve, reject, or forward to a review queue based on the business rules.

All subsequent HECM requests shall be routed to the contractor reviewers for approval or denial.

FHA Loan requests, with the exceptions of the following, shall be routed to HUD reviewers for further review and resolution:

Requests on FHA Loan extension type #1 where ‘Reason for Delay’ is ‘Missing Docs/Assignment’ or ‘Delay of Recording’ shall be auto denied.

Subsequent requests #2 or greater shall bypass business rules and be routed to HUD for review.

For Extension type #2 (HECM), maximum subsequent request allowed is 1. 2 or more subsequent requests are routed to contractor reviewers for review.

The system interface should contain a selection of two Variance types: HUD-90041 form for Pre-Foreclosure Sale and Other Variance.

HUD Administrators will have the capability of editing submitted Variances.

Reports

The system shall have ad hoc management reports available to designated HUD users and if desired, individual lenders.

The system shall have reports and all forms accessible for a period of 18 months.

Form HUD-90041 report format should not contain any modifications from the paper form.

A variance log shall be created with predefined parameters. These logs shall be capable of providing reports.

System generated reference number shall be assigned to all submitted variance.

Variance Pre-Foreclosure form shall be redesigned to fit the new form which became effective on December 24, 2008 per Mortgagee Letter 2008-043.

Reports shall be accessible by HUD Administrators or designees. The current reports include: 10% of Randomly Chosen Approved FHA Loan Extension Requests; 10% of Randomly Chosen Rejected FHA Loan Extension Requests; 10% of Randomly Chosen Approved HECM Loan Extension Requests; 10% of Randomly Chosen Rejected HECM Extension Requests; Extension Reports – filtered by Date Ranges, Lender, Type, Subsequent Request #, State, City, Zip Code, Status; Variance Reports – filtered by Date Ranges, Lender, Type, Subsequent Request #, State, City, Zip Code, Status; and Workflow report breakdown of requests submitted and number of requests worked by reviewers within a given period.

HUD Administrators

HUD Administrators shall have the capability of editing submitted Variances.

HUD Administrators shall have the capability to print submitted/completed Variance forms in a report format.

HUD Administrators shall have the capability of adding new HUD and Contractor reviewers and administrators to the system.

HUD Administrators shall have the ability to enable/disable a reviewer in the system.

HUD Administrators shall assign sequence numbers to enabled reviewers.

The system shall rotate submitted extensions among the enabled reviewers. If an enabled reviewer in the rotation queue is disabled, then the rotation shall be among the remaining enable reviewers.

HUD Administrators shall have the ability to replicate a lender by submitting extension and variance requests.

If a reviewer is disabled by an administrator, the system shall bypass the disabled reviewer and rotate submitted extensions among those reviewers that are enabled in the same sequence.

HUD Administrators shall have all reviewers’ access rights.

HUD Administrators shall have the ability to reassign cases by transferring a reviewer’s inbox to another reviewer.

HUD Administrators shall have the ability to assign and modify reviewers’ sequence number or priority order.

HUD Administrators shall have the ability to enable/disable a reviewer to submit extensions and variances on a lender’s behalf.

HUD Administrators shall have the ability to enable/disable a reviewer as an Administrator.

HUD Administrators shall have the ability to add/update/delete reviewers and administrators.

If a reviewer or administrator is deleted from the system, their record should still be retained in the database. A delete flag shall be added to the database so that “deleted” reviewers do not show up on any administrative or reviewer’s modules.

The delete functionality supersedes the “disabled” functionality. Prior to deletion, a confirmation prompt should be displayed to the administrator. It should ask “Are you sure you would like to delete “First Name Last Name” as a reviewer?

HUD Reviewers

HUD Reviewers shall have the ability to change extension length (days) requested by lender.

HUD Reviewers shall have the ability to override the subsequent request number provided by a lender during extension/variance request.

HUD Reviewers shall have the ability to enter the date for ‘Last Extension Expiration Date’ when applicable.

HUD Reviewers shall have the ability to enter the date for ‘First Legal Date’.

HUD Reviewers shall have the ability to enter the date for ‘Extension End Date’ if extension is being approved.

HUD Reviewers shall have the ability to select a denial reason from a list of denials when an extension/variance is being denied.

Reviewers’ inbox should be the main page displayed once a reviewer successfully logs in.

The reviewers’ inbox should have the combined extensions and variances pending requests displayed.

The system shall automatically display the next pending requests once a reviewer has finished reviewing a selected request.

Contractor Administrators

Contractor Administrators shall have the capability of editing submitted HECM extensions.

Contractor Administrators shall have the capability to print submitted/completed Extension of Time Form HUD-50012 in a report format.

Contractor Administrators shall have the capability of adding new contractor reviewers to the system.

Contractor Administrators shall have the ability to enable/disable contractor reviewers in the system.

The system shall rotate submitted extensions among the enabled reviewers. If an enabled reviewer in the rotation queue is disabled, then the rotation shall be among the remaining enable reviewers.

If a reviewer is disabled by an administrator, the system shall bypass the disabled reviewer and rotate submitted extensions among those reviewers that are enabled in the same sequence.

Contractor Administrators shall have all reviewers’ access rights.

Contractor Administrators shall have the ability to reassign cases by transferring a reviewer’s inbox to another reviewer.

Contractor Administrators shall have the ability to add/update/delete contractor reviewers.

If a reviewer or administrator is deleted from the system, their record should still be retained in the database. A delete flag shall be added to the database so that “deleted” reviewers do not show up on any administrative or reviewer’s modules.

The delete functionality supersedes the “disabled” functionality. Prior to deletion, a confirmation prompt should be displayed to the administrator. It should ask “Are you sure you would like to delete “First Name Last Name” as a reviewer?

Contractor Reviewers Contractor Reviewers will have the ability to override the subsequent request number provided by a lender during extension/variance request. Contractor Reviewers shall have the ability to review, approve, or reject HECM submissions.

Contractor Reviewers will have the ability to select a denial reason from a list of denials when an extension is being denied. Contractor Reviewers’ inbox should be the main page displayed once a reviewer successfully logs in.

The contractor reviewers’ inbox should have the pending extensions requests displayed.

The system shall automatically display the next pending requests once a reviewer has finished reviewing a selected request.

3.1 Summary of Requirements

3.1.1 Functional Requirements

· Lenders shall have the ability to access the EVARS via the World Wide Web to request for extensions by filling out HUD-50012 and request for variance by filling out HUD-90014.

· Lenders Mortgage Loan Number and FHA Case Number shall be automatically verified against SFIS data dump. Should there be any discrepancies between the information in SFIS and that submitted by the Mortgagor, the program shall request clarification and not accept request. These items would include incorrect mortgagee, incorrect mortgagor, failure of case number, and address to agree and other similar items.

· Validation of data entered through the system shall be performed before form submittal. Validation shall include the internal logic of the request; for example, if checking a particular item but the required information is not provided on the input field, HUD designed business rules shall be applied to the submitted information and shall be used to approve or deny the request.

· Address fields shall be auto-populated once a lender input their FHA Case and Mortgage Loan Number and the system verify and validate the input.

· If a lender logs into the system, but the system remains idle for a period of 20 minutes, the system shall time-out their session.

· The system shall flag 10% of all approved and rejected cases for HUD review.

· Cases may be denied or rejected if they fail to meet predefined form input validation process and if they fail programmed business rules. Cases that fail the business rules shall be routed to HUD for further review and lenders shall be notify that their application is rejected.

· HUD approved personnel shall have the ability to login to the system and approve or deny new registered users.

· When a request is approved by HUD through the system administrator’s interface, a confirmation message shall be displayed to the administrator that the user has been approved and logon information has been sent to the user.

· An email that contains the following user information shall be generated and sent out to the approved user:

· Unique 3-digit user code

· Unique user ID

· System-generated password.

· Unique user ID shall be system-generated and would be in this format: first letter of a user’s first name + first 3 letters of a user’s last name + day (dd) and month (mm) of the user’s birth.

· HUD approved personnel shall have the ability to log into the system to view cases that have being rejected based on business rules.

· HUD approved personnel shall have the ability to search through cases by providing a date, range of dates, and by selecting “Rejected” or “Approved” from an interface in the system.

· Electronic signature of the reviewer that has approved/rejected an extension and/or variance shall be embedded on the form HUD-50012 and HUD-90041. This functionality shall replace the need to generate transmittal reports.

· Transmittal functionality shall be disabled in the system.

· Lenders shall be assigned system-generated password for accessing their inboxes. At the initial logon with the system-generated password, lenders will be prompted to change their passwords.

· A user shall be forced to change their password at the first successful logon using their system-generated password. During the password change process a user shall be asked to choose from a list of generic questions and to provide answer to the question chosen.

The question and answer combination shall be used as a security measure if a user forgets their password and requests to have password emailed to them. Some questions that can be asked include:

· In what city where you born?

· What is your pet’s name?

· What is the model of your first car?

· What is your favorite color?

· What is the name of your High School?

· Passwords shall consist of 8 characters that are a combination of letters, 2 numbers, and special characters.

· Lenders shall authorize up to 130 employees to access the system. A 3-digit unique ID plus a lender 5-digit lender’s ID shall be assigned to each of the authorized employee.

· Notification of users to be deactivated in the systems shall be forwarded to HUD and CLS. CLS has the authority to disable a user when notified by lender that a user should be deactivated.

· Once the limit of 130 employees is reached for a particular lender, the system shall reject all subsequent registration.

· Prior to submission of registration, a user shall check a “checkbox” agreeing to abide by the usage rules and security measures of the system. A user cannot complete registration until the agreement checkbox is checked.

· If a lender does not access the system for a period of 45 days, they shall be prompted to change their password.

· The system shall approve, deny, or route extension requests based on HUD’s defined business rules. Information about the requests shall be posted to the mortgagee’s inbox.

· The system shall not make any decisions on variance requests. All variance requests shall be routed to contractor inbox for review.

· The system shall have the capability to allow users to attach documents to all their requests. Cases with attachments shall by-pass programmed business rules and be routed to CLS personnel for further review.

· The system shall display submitted dates for both extensions and variances. The submitted date shall be visible to all users on the extension and variance forms.

· Lenders shall have access to their submitted requests and HUD forms for a period of 18 months from the date of submission. During this period, they shall be able to print the forms at any time.

· Rejected requests for extensions shall be tracked by the system to determine the reason for rejection and this shall be used by HUD to determine training needs.

· The system shall track how often an extension request is made on a particular loan and shall flag any resubmitted requests for follow up action by HUD.

· The system shall make modifications to the Extensions of Time HUD-50012 form. The modifications are currently not captured on the form, but are part of the business rules.

· The system shall not allow lenders to submit duplicate requests on the same day for the same FHA case number on an Extension or Variance.

· The system shall not allow lenders to submit a subsequent extension or variance request if there is a pending request in the system on a FHA case number.

· Management reports shall be prepared and developed in accordance with HUD’s requests to monitor rejected extensions. These reports shall be accessible to HUD designated users and if desired, by the individual lender.

· Reports and all forms submitted through the system shall be accessible for 18 months after submission.

· A users’ manual that explains how to perform various actions shall be prepared and accessible through the system.

· Julian calendar shall be available to all users on the menu once logged in.

· dictionary of frequently used words and abbreviations shall be available to all users on the menu once logged in.

· A variance log shall be developed with HUD defined parameters. This log shall be capable of providing reports.

3.1.2 Improvements to Existing Capabilities

Evars Data Load Process:

HECM_Ref HECM_Ref derives its data from SMART_PROD.dbo.a_loan open loans, where loan_program_skey is 20.

This is accomplished by the following:

1) Begin Tranaction

2) Truncate HECM_Ref

3) Insert HECM_Ref from a_loan

4) Commit

The import file contains records that correspond to HECM_Ref. These records are removed prior to refreshing A43_Ref.

A43_Ref The downloaded file contains at least one record for the loans it represents. For this reason, we must exclude all but the most recent record for each loan.

Thereafter, we must update all existing records and insert any new records. This is accomplished by the following:

1) Delete records that exist in HECM_Ref

2) Delete records that are older duplicates within download file

3) Begin Transaction

4) Delete records in A43_Ref that are also in download file

5) Insert entirety of remaining download file records into A43_Ref

6) Commit

Change Request H0007 (11-5-2010) EVARS now provides a real-time update in SMART to capture all extension requests that are received and reviewed. This update creates an “auto-note” in SMART with the decision that was rendered in each loan and the date of the decision. This “auto-note” will document the extension request and the decision to the servicer. Approved extensions will note the approval date and the extension expiration date. Denied requests will record the denied decision. The HUD reference will be noted on all requests.

3.1.3 Timeliness

· The EVARS shall have a fast response time by tasking the database for most of the queries that is needed to run the application.

· Database tables shall be indexed to make searches and processes faster.

· The application shall provide standard response time of 2 seconds or less per page load by utilizing effective web page design, minimizing the use of large resolution images.

· Enough bandwidth shall be available so that at peak time, the system will respond just as it does when there are fewer users accessing the application.

· Regular load balancing and performance testing and tuning shall be conducted as part of routine maintenance and modifications to codes and database design shall be performed if and when needed.

3.2 Summary of Impacts

3.2.1 User Organizational Impacts

No elimination of responsibilities is envisioned for system administrators; HUD requests reviewers, or other personnel.

3.2.2 User Operational Impacts

The EVARS shall be designed to make its usage and operation easy and to minimize training requirements for lenders and other users. The system shall have a user-friendly, intuitive interface. The system shall be designed to be flexible, modular, and expandable. The number of users accessing the system simultaneously shall not affect performance and response time of the proposed system.

3.2.3 User Developmental Impacts

The sponsor/user shall provide all forms to be automated and additional data and information that will be needed to develop the system.

3.3 Assumptions and Constraints

· The EVARS shall be developed using web application middleware program ColdFusion MX 9.

· The backend Database Management System (DBMS) used for data storage will be Microsoft SQL Server 2005.

· Use of other programming and imaging tools shall be determined and utilized as required.

· EVARS shall be housed at the CLS site and at the disaster recovery center in Virginia Beach, Va.

· All data and application backup and security will be provided by CLS.

· CLS shall provide technical and helpdesk support for the system.

3.0 Proposed Methods And Procedures

Functional Requirements Document Page 3-9

4.0 DETAILED CHARACTERISTICS

4.0 Detailed Characteristics

Functional Requirements Document

DETAILED CHARACTERISTICS

4.1 Specific Performance Requirements

· EVARS shall be functional twenty-four hours a day, seven days a week to serve the dispersed lender community.

· EVARS shall provide convenient, user-friendly interfaces that minimize the need for end user and administrator training.

· User menu options and navigation shall reflect the users’ expectation and incorporate appropriate HUD terminology.

· EVARS shall provide online capability when network connectivity exists.

· EVARS shall support offline capability at the local level, synchronizing databases with the Data Center when connectivity is restored.

· EVARS shall provide requests for extensions and variances forms, reports, and present menu and user interfaces in accordance with user privileges.

· EVARS shall accommodate multiple independent users simultaneously.

· EVARS shall easily support expansion as the requirements for the system functionalities change and grow and usage of the system increases accordingly without degradation of service as perceived by the user.

· EVARS shall be programmed to accept scanned attachments from users.

4.1.1 Accuracy and Validity

Mortgage Loan Number and FHA Case Number shall be validated against the SFIS. All data input shall be validated using client side validations. Address shall be auto-populated once FHA Case number and Mortgage Loan number is verified and validate. Users will be forced to input predefined data type into input form.

4.1.2 Timing

· The EVARS shall meet timing requirements on the hardware and operating system.

· The EVARS shall meet timing requirements while supporting the maximum rated number of users.

· The EVARS shall meet timing requirements for 95% of all operations; that is, no more than 5% of the operations may exceed the stated time limit.

· The EVARS shall respond to all user inputs that do not require the loading of an HTML page within one second for 95% of all user input or field editing operations.

· The EVARS shall respond to all user inputs which require the loading of a new HTML page within 10 seconds - the page must be loaded into the browser and viewable - for 95% of all user input or editing operations, with the exception of reports.

4.1.3 Capacity Limits

The EVARS operation shall assume constrained bandwidth conditions and shall be able to handle 200 users simultaneously. The system shall be monitored regularly for degradation in performance and upgraded as needed.

4.2 Functional Area System Functions

Administration

· User Access - EVARS shall provide for the identification and authentication of valid users before providing access to the system. Validity shall be determined by comparing the lenders Lender ID and unique 3-digit code against data in the SFIS and EVARS users’ database. Once the user’s lender ID and code are validated, they will be prompted for their user ID and password combination. Administrators and reviewers shall be authenticated by the system. Data will be entered through the user’s browser. Remote users shall connect directly to the EVARS via their Internet Service Provider (ISP) and the World Wide Web. EVARS website is https://evars.hudtulsa.org

· User Profiles - Once a lender has been authenticated, lender profiles are retrieved from the database.

· Assignment or Roles and Privileges - Assigned user roles shall dictate user privileges. A user may be assigned to multiple roles allowing each user to serve in one or more roles as an administrator, lender, reviewer, etc. A user with multiple roles while logged-in as a lender shall retain only lender privileges. General roles include, but are not limited to:

· Lender – A lender is authorized access to submit requests for extensions and variances. Lenders may view items, their inbox, print submitted forms, and other information. A lender may authorize up to 130 employees to have access to the system. Lenders’ 5-10 digit ID plus a unique 3-digit ID shall be assigned to each designated employee. Lenders shall be able to view requests submitted by all other employees of the same organization in the lender’s inbox.

Certain lenders shall be allowed to register in the system multiple times using different lender IDs.

· HUD Reviewer – A user assigned reviewer status may view any lenders inbox and information, but shall not be able to change or edit lenders submitted data. Reviewer can also be an Administrator. Can replicate a lender by entering extension and variance requests.

· Contractor Reviewer - A user assigned contractor reviewer status shall have the ability to review some of the extensions that the business logic specifies to be routed to contractor reviewers and all variances submitted through the system.

· System Administrator – A user with assigned responsibility for general system administration shall have access to lenders inboxes and management reporting tools. He shall have the ability to approve or deny new user registration, request scheduled or ad hoc reports on the status of the system or individual lenders. Administrators shall have the ability to enable/disable reviewers and reassign cases in the system, grant administrative rights to reviewers, set sequence number, and can replicate a lender by entering extension and variance requests.

· Developer – A developer is a user with the responsibility for developing the system and content and may be able to perform all roles specified above as authorized.

HUD-50012 Mortgagee’s Request for Extensions of Time Form

· Lenders shall have the ability to select a choice of either FHA Case loan or HECM loan on which to submit an extension.

· If the FHA Case loan type is selected, a lender shall have the option to select from the following extension types: #1, 7, and 8.

· If the HECM loan type is selected, a lender shall have the option to request just the extension type #2.

· Data shall be entered manually by the lender. Input data shall be validated against SFIS data dump and business rules for accuracy.

· Unsuccessful requests shall generate and return appropriate responses to the lender citing the reason for failure. Successful requests shall be processed according to defined business rules.

HUD-90041 Request for Variance Form

· Lenders shall have the ability to select a choice of either a Pre-foreclosure Sale Procedure or Other on which to submit a variance.

· Data shall be entered manually by the lenders. Input data shall be validated against the SFIS data dump and business rules for accuracy.

· Variance requests shall bypass all business rules and be routed to HUD reviewers for review.

· Unsuccessful requests shall generate and return appropriate responses to the lender citing the reason for failure. Successful requests shall be processed, recorded in the database and forwarded to the HUD for review and final resolution

Launch and Control

· EVARS shall be capable of launching web-based forms, reports, and logs. All services shall be accessible from a user’s web browser.

· EVARS shall provide the capability for all users to launch and view all forms, reports, and logs that are within the scope of the privileges of the user to access. For lenders, this includes their inboxes and information regarding submitted requests.

· EVARS shall track the requests for extensions that are rejected to determine the cause and this tracking shall be used by HUD to determine training needs.

· EVARS shall not allow unauthenticated users to access lenders inboxes and management reports.

· During the log-in process, the delivered lender profile data will include the latest bookmarks recorded during the lender’s last use of the system

Cataloging

· EVARS shall log requests for variances with HUD predefined parameters.

· Information on accepted forms shall be accessible for viewing and printing for a period of 18 months from the time of submission.

· Information on rejected extensions shall be accessible for viewing and printing by authorized users for a period of 18 months from the time of submission.

· Reports prepared in accordance with HUD’s requests to monitor rejected extensions shall be accessible and printable by authorized users for a period of 18 months from the time of submission.

Reports

· Reports shall be generated by logs using HUD predefined parameters.

· EVARS administrator shall be able to respond to ad hoc queries applicable to system and resource usage/scheduling.

4.3 Input and Output

· EVARS shall gather data from lenders to populate extensions and variances forms.

· EVARS shall forward collected information to HUD personnel for review, approval, and rejection.

· Requests status shall be available through the EVARS lenders inboxes.

· EVARS shall accept input from the user’s browser and provide appropriate responses to requests to the same.

· EVARS shall generate and deliver reports to authorized users as required.

4.4 Failure Contingencies

· Backup: EVARS shall provide nightly backup of database and application onsite. Additionally it is backed up to Barracuda Networks secure servers over the internet and replicated at the disaster recovery site in Virginia Beach, Va.

· SLA: A service level agreement with the Internet Service Provider, EasyTEL Communications, Inc. is in place and guarantees 99.999% uptime.

4.0 Detailed Characteristics

Functional Requirements Document Page 4-5

5.0 DESIGN CONSIDERATIONS

5.0 Design Considerations

Functional Requirements Document

DESIGN CONSIDERATIONS

5.1 System Description

5.2 System Functions

· EVARS shall provide capabilities for requests for extensions and variances by lenders, reviewers, and administrators through via the World Wide Web.

· EVARS shall allow users with valid lender ID to fill out and submit registration.

· EVARS shall track the number of users registered for a particular lender.

· A maximum of -130 lenders are allowed to register for a particular lender ID.

· When the maximum number registration is reached for a particular lender, the system shall reject all subsequent registration.

· EVARS shall provide the capability for HUD approved administrators to access the system and approve or reject a registered user.

· When a user is approved through the system administrator interface, an email containing a 3-digit code, unique user name and password shall be generated and sent to the user.

· Lenders FHA Case Number shall be validated against the SFIS before requests can be accessed or completed.

· EVARS shall track accepted and rejected submissions and generate management reports in accordance with HUD’s requests to monitor extensions.

· EVARS shall have accepted and rejected requests accessible and printable to authorized users for a period of 18 months.

· The EVARS shall allow reviewers and administrators to view requests and generate reports.

5.3 Flexibility

· EVARS shall accommodate multiple independent users simultaneously and be capable of supporting variable operational configurations due to the different user populations.

· EVARS shall easily support expansion as the system requirements and functionalities grow and use of the system increase accordingly.

· EVARS shall accommodate expansion without degradation of service as perceived by the user.

5.0 Design Considerations

Functional Requirements Document Page 5-2

6.0 ENVIRONMENT

6.0 Environment

Functional Requirements Document

ENVIRONMENT

6.1 Equipment Environment

The hardware equipment environment consists of the following:

· O/S Windows 2003 Standard with IIS 6

· Virtual Server utilizing VMware

· Primary Connectivity: 1 GB

· Firewall: Sonicwall NSA 2400 UTM

6.2 Software Environment

This system will be developed on:

· ColdFusion MX 9

· Microsoft SQL Server 2005

· Other tools shall be utilized as needed

6.3 Communications Requirements

6.3.1 Communications Overview

The EVARS shall depend on the CLS communication network infrastructure for LAN connectivity between the web-based system and local servers. Remote users shall have access to the EVARS servers via the World Wide Web. A service level agreement with the Internet Service Provider, EasyTEL Communications, Inc. is in place and guarantees 99.999% uptime.

6.3.2 Communications Hardware

The EVARS shall depend on the CLS communications network and workstation LAN adapters for connectivity between system components. There are no additional hardware requirements.

6.3.3 Communications Software

The EVARS user browser shall be vendor and version independent to support communications over standard TCP ports supported by the CLS network infrastructure. The EVARS shall support the use of third-party communication applications, such as e-mail and chat.

6.4 Interfaces

The EVARS shall communicate over existing network circuits using only the following standard and product based protocols and TCP port numbers:

· HTTP - Port…