The User Requirements Document describes in as much detail as possible the request for development or change. During this phase, the document often evolves from a very general first draft, growing as continuing discussion and issue resolution produces more detail, and finally results in a final version with very specific and detailed information addressing all business aspects of the desired development effort. This document is important since it describes in detail the business nature of the system to be developed or changed. Time spent up-front thinking through these issues saves time and reprogramming in the later design and development phases. Once the User Requirements have been accepted by the Business Owners, any subsequent changes must go through the project change request process.

Cover Sheet

The cover sheet identifies the system, the title of the request, and the name of the person who prepared it and the date of preparation. The word "Draft" must be shown on all documents issued prior to the final approval. A space for approval signature and date is also on the cover sheet.

Table of Contents

A table of contents will follow the document cover sheet. The sections may have sub-sections that should also be identified in the table of contents

Document Sign-Off / Signatory Approval

Until approval is received, the document is assumed to be in a draft state. Once approvals of the phase output are obtained, the original copy of the signed approval page must be stored in an appropriate location. Upon approval, the document is considered a final version, the word “Final” should be shown on the cover page, and no changes can be made unless an accepted change request form is submitted and accepted by the Business Owner and Project Manager.

Overview

The Overview includes the general description and scope of the project. It is meant to describe the problem or issue that necessitates a systems change. Do not include the proposed solution in this section. Include references to the specific laws, regulations or policies, if any, that requires this change. Also include how this change supports the Department’s strategic plan. A project overview can usually be taken from the Project Charter or Project Management Plan

Per House Bill 1708 – 2005 General Assembly, all recipients of TANF must be a U.S. Citizen or qualified alien in order to receive assistance. Aliens must continue to provide the documentation currently required to prove qualified alien status. Citizens age 19 or older must now provide affirmative proof of citizenship or legal presence. Such proof can include documentation to prove citizenship (such as a birth certificate) or a social security number.

If a person claims to be a citizen but does not have a social security number or proof of

citizenship, eligibility may exist up to 90 days or until it is determined whether or not the person is legally present. If a social security number or proof of citizenship is not provided by the end of 90 days, the person is ineligible. Current recipients age 19 or older must comply by the next

redetermination.

All recipients of Medicaid age 19 or older must provide proof of citizenship or legal presence in the U.S. Per Medicaid policy, an applicant can sign an affidavit declaring their U.S. Citizenship or legal presence in the U.S. This affidavit will act as temporary proof (or verification) for a period of 90 days so that a person can receive benefits. After 90 days, if affirmative proof of citizenship or legal presence has not been provided, the person is ineligible.

Additionally, all programs (Food Stamps, Medicaid, & TANF) require that SSN be verified prior to recertification. Therefore, if SSN verification is not provided at renewal for an individual, that individual should not be allowed to enroll in a program.

1. Project Scope

Describe in general the purpose of the project and proposed solution in this document. The project scope can usually be taken from the Project Charter or Project Management Plan.

1.1 Project Schedule

List dates for project milestones.

General Design and Project Approval: Enter date approval due from Business Owner

User Acceptance Testing: Enter date system is ready for User Testing

Implementation: Enter date system in production

2. User Requirements

This section describes the proposed changes requested. It should be written from a business perspective and include specific new or changed processes, data, reports, etc. This is a description of what the final product will accomplish. To generate requirements, review the capabilities and uses of the existing system and how it should be changed to accomplish the new purpose.

Document what you want the new system to do differently, what should remain the same as today’s system (if one exists), how the information should be presented to a user, how data should be shared between other computer systems, and all other business details that can be identified.

For easier reference in discussions and for future use by other phases, each new requirement should be given a unique number. It is recommended to use a sequential numbering system.

All requirements should be unambiguous. For example, does the requirement, “users can search by first name and last name,” mean that users can search by first name or last name or does it mean that users can search by first name + last name?

Each requirement should be noted with a priority level. You should use a 3-point scale such as 1) must be included, 2) should be included, if possible and 3) inclusion is optional, nice to have.

2.1 General Description of the New Process and Its Purpose

Describe the general process this requirement creates (new or changed functionality, new workflow, additional data collection, new or changed report, document production such as help information, etc.). Include a brief description of how these changes are expected to benefit the business. This section provides a thorough description of what the final product is supposed to accomplish.

First, this SR calls for the creation a new field in ADAPT, preferably on the AEDEM1 screen, for MC Legal Presence Affidavit (Y/N). This will be a purely informational field and should not be used in EDBC. The field needs to exist for all person numbers on a case (similar to the other fields on AEDEM1).

Second, a new report should be created in the ADAPT system that would run on the 19^th of each month. The report should display all enrollees over the age of 19 who have not met the citizenship or legal presence verification requirements for greater than 30 days from the BDOA. This report will be for Medicaid and TANF cases. The report should display the number of days the enrollee on an active case has not met the requirements. This report will enable workers to proactively identify enrollees who need to submit verification.

Third, the new process will create an alert for workers who have an enrollee in their caseload whose citizenship or legal presence has not been verified for greater than 55 days from the BDOA. The alert should tell the worker to contact the enrollee and let them know they must provide verification of citizenship or legal presence.

Fourth, if the client reaches 90 days from the date that TANF and/or Medicaid were granted and citizenship or legal presence is still not verified, a second alert should be generated. This alert would tell the worker to take action on the case. The 90 day criterion does NOT apply to the Food Stamp program.

Finally, if a client’s case is being renewed and SSN verification has still never been provided, an edit should be put in place so that the client fails. Until the client provides SSN verification, the worker should be unable to grant a program’s recertification. This applies to all programs.

2.2 Functionality

This is the set of requirements that defines what the product is supposed to do at a systems or user level. If needed for clarity, these requirements might also include what the product will not do.

The following requirements should be implemented in this SR.

Requirement #	Priority	Description
1.0	High	Create a new field called MC Legal Presence Affidavit with Y/N values. It should only be required for MC cases. This new field should be at a person level, preferably on the AEDEM1 screen. It should not impact EDBC.
2.0	High	Create a report in ADAPT on the Statistical Report Menu that runs on the 19^th of the month and includes a list of enrollees over the age of 19 on active cases whose citizenship or legal presence has not been verified for greater than 30 days from the BDOA.
2.1	High	The ADAPT report should include the following fields: · Enrollee Name · Enrollee ID · Case Name · Case Number · Number of Days Pending (calculate how many days the citizenship or legal presence has been pending verification from the BDOA) · Programs (list which programs the client is currently enrolled in) · MC Legal Presence Affidavit · FIPS (only if statewide or regional report)
2.2	High	The report should have a submenu that allows the user to select one of the following options: · Report Month · Statewide list of individuals – totals at bottom · Regional (service area) list of individuals – enter region/service area code – totals at bottom · FIPS list of individuals – enter FIPS code – totals at bottom · Caseload Number – enter caseload in combination with FIPS code
2.3	High	The report should include an open field in front of the client name. When placing the cursor next to a name and transmitting, the client will be taken to the AEDEM1 screen for this individual. If the client is in the worker’s caseload, the screen will be in update mode. Otherwise, it will be inquiry.
2.4	High	Report should be able to be printed.