Docstoc

Proposed Jobs Lookup Template

Document Sample
Proposed Jobs Lookup Template Powered By Docstoc
					               OFFICE OF SYSTEMS INTEGRATION

               REQUEST FOR PROPOSAL OSI 7100-181
                  UNEMPLOYMENT INSURANCE
                   MODERNIZATION PROJECT




            SECTION 6C – TECHNICAL REQUIREMENTS

                                       APRIL 8, 2008
                                           ADDENDUM 3

                                           ISSUED BY:

                                    STATE OF CALIFORNIA

                           DEPARTMENT OF GENERAL SERVICES
                           TECHNOLOGY ACQUISITIONS SECTION
                               707 3RD STREET, 2ND FLOOR
                              WEST SACRAMENTO, CA 95605




1673d445-8846-415b-9b58-82958e8c824d.doc
OFFICE OF SYSTEMS INTEGRATION                                                                       RFP OSI 7100-181
UIMOD PROJECT                                                                             SECTION 6C — PAGE 2 of 159



                                       Table of Contents
                              Section 6C Technical Requirements
6C         TECHNICAL REQUIREMENTS .......................................................................................... 6
6C.1        FUNCTIONAL REQUIREMENTS ..................................................................................... 7
6C.1.1      General Functional Requirements ................................................................................... 8
6C.1.2      Continued Claims Functional Requirements ..................................................................10
6C.1.3      CCR Functional Requirements ......................................................................................14
6C.2        SYSTEM INTERFACES ..................................................................................................34
6C.2.1      Overview of External System Dependencies .................................................................35
6C.2.2      Global Interface Requirements ......................................................................................38
6C.2.3      Detailed Integration Requirements .................................................................................40
6C.2.3.1.1  Request 1099 Information System and Interface Characteristics ..................................40
6C.2.3.1.2  Request 1099 Information Integration Requirements ....................................................41
6C.2.3.1.3  Request for Duplicate 1099 System and Interface Characteristics................................41
6C.2.3.1.4  Request for Duplicate 1099 Integration Requirements ..................................................41
6C.3        POLICY AND REGULATION ..........................................................................................78
6C.3.1      Policy and Regulation Requirements .............................................................................78
6C.4        REPORTING / BUSINESS INTELLIGENCE REPORTING REQUIREMENTS ..............79
6C.4.1      Real Time Information ....................................................................................................81
6C.4.2      Day-to-Day Management ...............................................................................................81
6C.4.3      Business Planning Information .......................................................................................81
6C.4.4      Decision Support Information .........................................................................................82
6C.4.5      Business Intelligence and Reporting: Tools Requirements ..........................................82
6C.4.6      Business Intelligence and Reporting: Constraining Requirements ...............................85
6C.4.7      Business Intelligence and Reporting: Ad-hoc Reporting Requirements .......................86
6C.4.8      Business Intelligence and Reporting: Standard Reporting Requirements .....................88
6C.4.9      Business Intelligence and Reporting: Data Requirements ............................................90
6C.5        CCNPAU REQUIREMENTS (CALNET 2) ......................................................................93
6C.5.1      CALNET 2 and CCNPAU ...............................................................................................93
6C.5.2      Section Deleted ..............................................................................................................93
6C.5.3      Section Deleted ..............................................................................................................93
6C.5.4      Section Deleted ..............................................................................................................93
6C.5.5      Section Deleted ..............................................................................................................93
6C.5.6      Section Deleted ..............................................................................................................94
6C.5.7      Section Deleted ..............................................................................................................94
6C.5.8      Section Deleted ..............................................................................................................94
6C.5.9      Section Deleted ..............................................................................................................95
6C.5.10     Section Deleted ..............................................................................................................97
6C.5.11     Section Deleted ..............................................................................................................97
6C.5.12     Section Deleted ..............................................................................................................97
6C.5.13     Section Deleted ..............................................................................................................97
6C.5.14     Section Deleted ..............................................................................................................98
6C.5.15     Section Deleted ..............................................................................................................98
6C.5.16     Section Deleted ..............................................................................................................98
6C.5.17     Section Deleted ..............................................................................................................98
6C.5.18     Section Deleted ..............................................................................................................99
6C.5.19     Section Deleted ..............................................................................................................99
6C.5.20     Section Deleted ..............................................................................................................99
6C.5.21     Section Deleted ..............................................................................................................99
6C.5.22     Section Deleted ............................................................................................................102
6C.5.23     Section Deleted ............................................................................................................104
6C.5.24     Section Deleted ............................................................................................................108
6C.5.25     Architectural Considerations ........................................................................................109
6C.5.26     System Security Requirements ....................................................................................112

1673D445-8846-415B-9B58-82958E8C824D.DOC                                                                                     ADDENDUM 3        APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                                                  RFP OSI 7100-181
UIMOD PROJECT                                                                        SECTION 6C — PAGE 3 of 159


6C.6      CONTINUED CLAIMS REDESIGN REQUIREMENTS.................................................114
6C.6.1    Major System Conditions .............................................................................................115
6C.6.2    Operational Scenarios ..................................................................................................118
6C.6.3    System Performance Characteristics ...........................................................................119
6C.6.4    Adaptability and Extensibility ........................................................................................121
6C.6.5    System Security ...........................................................................................................124
6C.6.6    Audit Logging ...............................................................................................................133
6C.6.7    Information Management .............................................................................................139
6C.6.8    System Operations .......................................................................................................143
6C.6.9    Design Constraints .......................................................................................................146
6C.6.10   Architecture Requirements ...........................................................................................147
6C.6.11   Business Rules Framework..........................................................................................155




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                                                  ADDENDUM 3         APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                                                              RFP OSI 7100-181
UIMOD PROJECT                                                                                    SECTION 6C — PAGE 4 of 159



                                        Table of Figures
                               Section 6C Technical Requirements
FIGURE 6C1:           OPERATIONAL REPORTING AND BUSINESS INTELLIGENCE
                      ENVIRONMENT ............................................................................................................. 79
FIGURE 6C2: FIGURE DELETED............................................................................................................ 99

FIGURE 6C.3: CONCEPTUAL PROCESS ARCHITECTURE ............................................................. 110

FIGURE 6C.4: FIGURE DELETED......................................................................................................... 111




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                                                               ADDENDUM 3    APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                                                        RFP OSI 7100-181
UIMOD PROJECT                                                                              SECTION 6C — PAGE 5 of 159



                                Table of Tables
                      Section 6C Technical Requirements
TABLE 6C.1   TABLE DELETED........................................................................................................... 93

TABLE 6C.2   TABLE DELETED........................................................................................................... 94
TABLE 6C.3   CALIFORNIA POPULATION DATA AND PROJECTIONS FROM US CENSUS
             BUREAU ....................................................................................................................... 121
TABLE 6C.4   CALIFORNIA WORKFORCE AND UNEMPLOYMENT RATES .............................. 121

TABLE 6C.5   CALIFORNIA UI CONTINUED CLAIMS WORKLOAD AND PERFORMANCE ...... 121




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                                                            ADDENDUM 3    APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                       RFP OSI 7100-181
UIMOD PROJECT                                             SECTION 6C — PAGE 6 of 159




6C       TECHNICAL REQUIREMENTS
This section of the Request for Proposal (RFP) is organized to help the Contractor
understand the areas of overlap as well as the areas that are specific to each subproject.
This section is organized as follows:
     1. Functional Requirements:
       a) General Functional Requirements – These are the functional requirements for
          both delivery channels. Many functional requirements are common to both
          the Web Phase 1 and 2 and the IVR Phase 2.
       b) Continued Claims Functional Requirements – The functional requirements
          address the initial and subsequent releases of the certification process.
       c) CCR Functional Requirements – These requirements are specific functionality
          for the CCR subproject.
     2. System Interfaces – both the IVR and the Web applications will share the same set
        of interfaces to external systems.
     3. Policy and Regulation Requirements – the Unemployment Insurance
        Modernization (UIMOD) Project is governed by policies and regulations of the State
        of California.
     4. Reporting/Business Intelligence – while there are unique reporting requirements for
        each subproject, usage of an enterprise data warehouse is a shared requirement.
        Seeing all the reporting requirements together will help the Contractor understand
        the scope of work required.
     5. CCNPAU Subproject Requirements – technical requirements specific to the IVR
        CCR Phase 2.
     6. CCR Subproject Requirements – technical requirements specific to the CCR
        subproject.
     7. Mandatory/Optional – Requirements for the Reporting/Business Intelligence and
        Web Content Management are Mandatory/Optional – it is mandatory that the
        bidder respond and provide cost estimates, but it is the UIMOD project‘s option to
        include the requirements in the scope of the project.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                        ADDENDUM 3    APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                       RFP OSI 7100-181
UIMOD PROJECT                                             SECTION 6C — PAGE 7 of 159




6C.1 FUNCTIONAL REQUIREMENTS
The functional requirements for the new Systems are defined below. These were obtained
from interviews with the user community in which use cases were defined. From these
preliminary use cases, requirements were extracted and are included here.
At the core of the new functionality is the continued claims process. Continued claims will be
implemented in phases, which are described in the continued claims processing functional
requirements section.


See Appendix C, CCR Use Cases, for reference.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                         ADDENDUM 3      APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 8 of 159




6C.1.1        General Functional Requirements
                                                                                                  Bidder
Requirement
                                          Requirement                                 State Use   Agrees
Number
                                                                                                   (Y/N)
   1          Requirement Deleted                                                                  N/A
   2          Requirement Deleted                                                                  N/A

   3          Requirement Deleted                                                                  N/A

   4          Requirement Deleted                                                                  N/A

   5          Requirement Deleted                                                                  N/A

   6          Requirement Deleted                                                                  N/A

   7          Requirement Deleted                                                                  N/A

   8          Requirement Deleted                                                                  N/A

   9          For the Web and IVR, the system must allow the Public User to select    FCTN892
              and order public forms that do not require prior system
              authentications.
   10         Web: The System must allow the Public Customer (Claimant,               FCTN893
              Employer) to enroll for an on-line account (See Appendix C - CCR
              Use Cases, On-line Enrollment).
   11         Web: The System must allow a Public User or Public Customer to          FCTN894
              browse and search for information on the EDD Web site using
              keywords and keyword phrases.
   12         Mandatory/Optional                                                      FCTN895
              Web: The System must include a Content Management System with
              the functionality to support the managing of content and allow EDD
              staff to publish information on the Web site.
   13         The System must be designed around and have the functionality to        FCTN896
              manage workflow and work queues associated with different staff
              roles.
   14         The System must be able to manage multiple work queues.                 FCTN897
   15         The System must be able to route claims with exceptions to different    FCTN898
              work queues.
   16         The System must allow Managers to associate Staff with one or           FCTN899
              multiple workload queues.
   17         The System must allow authorized state staff to route work to another   FCTN900
              work queue (based on preset and configurable routing conditions).
   18         The System must monitor the work queues and based on                    FCTN901
              configurable parameters, the system must be able to alarm a
              Manager(s), reroute work, and escalate work.
   19         The System must allow the Workflow Administrator to allocate and        FCTN902
              reallocate workload between centers/work queues.
   20         The System must enable the Workflow Administrator to allocate           FCTN903
              workload across Adjustors. (See Appendix C - CCR Use Cases,
              Manage Workflow use case).

1673D445-8846-415B-9B58-82958E8C824D.DOC                                              ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 9 of 159


                                                                                                 Bidder
Requirement
                                          Requirement                                State Use   Agrees
Number
                                                                                                  (Y/N)
   21         The CCR subproject must use the IVR system as developed by the         FCTN1007
              CCNPAU subproject.
   22         Requirement Deleted                                                                 N/A
   23         The IVR system must interface with the CCR System to update            FCTN1010
              eligibility.
   24         Requirement Deleted                                                                 N/A
   25         The IVR system must allow Claimant to order forms.                     FCTN1012
   26         Requirement Deleted                                                                 N/A
   27         Requirement Deleted                                                                 N/A
   28         The System must allow Claimant to change address.                      FCTN1015
   29         The System must allow Claimant to change phone number(s).              FCTN1016
   30         The System must allow Claimant to get list of appointments.            FCTN1017
   31         The System must allow Claimant to cancel appointments.                 FCTN1018
   32         Requirement Deleted.                                                                N/A

   33         Requirement Deleted                                                                 N/A

   34         Requirement Deleted                                                                 N/A

   35         Requirement Deleted                                                                 N/A

   36         Requirement Deleted                                                                 N/A

   37         Requirement Deleted                                                                 N/A

   38         Requirement Deleted                                                                 N/A

   39         For caller inquiries about determination appointments, the UCD         FCTN1204
              system must look-up appointment dates and times in the Scheduling
              System (UISS) in response to a caller inquiry and SPEAK the results.
   40         Requirement Deleted                                                                 N/A




1673D445-8846-415B-9B58-82958E8C824D.DOC                                             ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 10 of 159



6C.1.2        Continued Claims Functional Requirements
The Unemployment Insurance Program requires claimants to certify their eligibility for
benefits on a bi-weekly basis. Certifications are processed and result in benefit payments to
claimants. The IVR Phase 2 and Web Phase 1 and 2 will include functionality to conduct
certification for Continued Claim eligibility.
The initial release into production of the continued claims process will focus on rapidly
providing a simple continued claims process, modeled after the current paper process, but
delivered via the web channel. Due to different technologies, initially the Web may not be
able to collect all information currently collected through the paper processes, such as
address changes and work and wage information. The goal for the initial release is to
reduce the number of forms processed through the paper channel.
Subsequent releases will add more functionality and more sophisticated rules processing of
user responses, with rules determining if an eligibility issue exists. One of the main goals is
to reduce the number of forms requiring staff intervention and eliminate the need to reissue
forms because they are incomplete, mailed early, or include both yes and no answers to the
same question.

6C.1.2.1      Continued Claims (Certify for Benefits Phase 1 Web)

Following are the functional requirements for continued claims (Certify for Benefits and
Phase 1 Web). The initial release, Phase 1 Web, will contain a subset of these
requirements.
                                                                                                   Bidder
Requirement
                                            Requirement                                State Use   Agrees
Number
                                                                                                   (Y/N)
   41         The System must provide a message to advise filing by another            FCTN740
              channel for claimants to file by paper or if available via the web.
   42         The System must calculate and provide the claimant the beginning         FCTN741
              and end dates of each time period the claimant is entitled to certify.
   43         The System must provide the ―false statement advice‖ and                 FCTN742
              instructions.
   44         The System must collect eligibility information from the claimant.       FCTN743
              Current policies require capturing the following:
              a) Available to work?
              b) Available to accept full-time or part-time employment?
              c) Look for work?
              d) Refuse work offer?
              e) Able to work?
              f) In approved school or training?
              g) Did you work and/or have earnings?
   45         The System must ask the caller whether Federal Income Tax                FCTN744
              withholding is requested and collect the answer.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                               ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 11 of 159


                                                                                                       Bidder
Requirement
                                            Requirement                                    State Use   Agrees
Number
                                                                                                       (Y/N)
   46         The Phase 1 Web release must route certification information to the          FCTN745
              legacy Unemployment Insurance System (UIS) in the same fashion as
              the 4581 continued claims paper process. (The scanned data is
              written to a file and transmitted throughout the day to the mainframe
              using file transfer protocol.)
   47         Based on claimant answers to questions, the System must instruct the         FCTN1209
              claimant to submit a paper claim when that is necessary.
   48         The System must collect information regarding the claimant's ability to      FCTN1210
              work and if unable, then collect the number of days the claimant was
              unable to work.
   49         The System must provide a confirmation number to the claimant after          FCTN858
              the claimant has certified for benefits.
   50         The System must establish the time period for which the claimant             FCTN979
              may certify.
   51         The System must advise the Claimant of the time intervals for which          FCTN980
              the Claimant is eligible to certify.
   52         The System must validate, through a series of questions, that the            FCTN981
              current eligibility information in the system is both correct and current.
   53         The System must determine the order and type of questions based              FCTN982
              on the outcome of the previous question as well as the information on
              the claim.
   54         After the System has collected all of the information, the System must       FCTN983
              summarize the information provided by the Claimant and display or
              read back the information for verification.
   55         The System must not permit the Claimant to go back and change                FCTN984
              his/her answers after submission of the certification.
   56         The System rules must determine whether the Claimant met the                 FCTN985
              eligibility requirements.
   57         The System must perform validation on all information on the                 FCTN986
              continued claim as well as validation between combinations of
              answers to ensure they are logically consistent. This includes
              validation to prevent premature filing.
   58         The System must calculate and notify SCDB of the payment and                 FCTN987
              reduction amounts.
   59         The System must initiate the payment process via the SCDB system.            FCTN988
   60         If not entitled to certification, the System must notify the Claimant of     FCTN989
              the reason for ineligibility and his/her options.
   61         The System must notify the Claimant of the results of the certification      FCTN990
              and when they can next certify.
   62         The System must allow the certification to be kept in a pending state        FCTN991
              (if a pending condition exists).
   63         The System must track time from the first compensable week ending            FCTN992
              date to the date of the first payment.

1673D445-8846-415B-9B58-82958E8C824D.DOC                                                   ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 12 of 159


                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   64         The System must capture and report on certification date, payment         FCTN993
              date and amount.
   65         The System must recognize if there is a potential for a first payment     FCTN994
              and track time of this event until disposition of the week is resolved.
              This information is required by the Department of Labor (DOL) to
              measure performance of EDD payments.
   66         The System must implement rules to enable timely processing of            FCTN995
              claims and meet established policies and regulations.
   67         The System must provide operational data on claims in various             FCTN996
              stages of the workflow (e.g., total elapsed time, staffing resources
              associated with certifying claim) for use by the reporting system.
   68         If required to submit work search, the System must capture work           FCTN997
              search information (where Claimant looked for work) and use this to
              validate that Claimant was actively seeking work.
   69         The System must store the submission and trigger continued claims         FCTN998
              processing if no exceptions exist (e.g., Calculate Payment and Initiate
              Payment/Disbursement).
   70         If Claimant is part of the partial program, the System must be able to    FCTN999
              apply rules that govern certification weeks which are different from a
              standard continued claim. (Note: for partials, the certification
              conforms to the Employer‘s payroll weekending date rather than the
              standard Saturday weekending date.)
   71         The System must allow a partial Claimant to retain the non-standard       FCTN1000
              weekending date when the Claimant no longer meets the partial claim
              requirements.
   72         The System must check the information against a set of pre-               FCTN1001
              established fraud conditions.
   73         If a fraud condition criterion is met, the System must generate a fraud   FCTN1002
              alert (i.e. a notification to a fraud analyst).
   74         The System must notify Profiling as a result of the first payment.        FCTN1003
   75         The System must notify base period Employer as a result of the first      FCTN1004
              payment.
   76         The System must receive information regarding the presence of an          FCTN1005
              active resume from CalJOBS.
   77         The System must receive information regarding the attendance of a         FCTN1006
              scheduled job service appointment from PASS/ACES.
   78         The System must determine and identify the method of certification        FCTN1282
              (e.g. IVR, Web, Paper).
   79         The System must accept data from the Optical Character Recognition        FCTN1283
              (OCR) scanning system.
   80         The System must identify certifications that contain unscannable          FCTN1284
              data.



1673D445-8846-415B-9B58-82958E8C824D.DOC                                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                          RFP OSI 7100-181
UIMOD PROJECT                                               SECTION 6C — PAGE 13 of 159


                                                                                                 Bidder
Requirement
                                         Requirement                                 State Use   Agrees
Number
                                                                                                 (Y/N)
   81         The System must route unscannable certifications to a work queue for   FCTN1285
              manual intervention.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                             ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                     RFP OSI 7100-181
UIMOD PROJECT                                          SECTION 6C — PAGE 14 of 159



6C.1.3        CCR Functional Requirements
The following discussion contains information and requirements specific to the CCR
subproject extracted from the CCR Use Cases developed in conjunction with Gartner. A
use case map, list of use cases, user descriptions, and details on each use case are
contained in Appendix C - CCR Use Cases.

6C.1.3.1      Overview of CCR System Capabilities

The major capability groupings within the CCR System are as follows:
 1. On-line transaction processing: This includes processing customer service
    inquiries, updating certification information, resolving continued claims exceptions,
    requesting lost or stolen check forms and processing decisions.
 2. Customer self-service: This includes capabilities for Claimants to manage their
    accounts and submit continued claims and additional claims.
 3. Reporting: This includes queries, interactive on-line analytical processing and
    recurring reports.
 4. Fraud detection: The CCR System includes reporting capabilities functionality for
    fraud detection and functional capabilities for fraud prevention.
 5. Manage workflow: This includes the ability to monitor and manage workflow.
 6. Managing business rules: This includes modifying business rules to meet
    regulatory or other changes.
 7. Publish content: The CCR subproject will provide Unemployment Insurance (UI)
    Branch Subject Matter Experts with capabilities for publishing content to the Web.

6C.1.3.2      General CCR System Conditions

In addition to paper certification, Public Customers will access the CCR System via the Web
or IVR. The major areas of requirements include on-line enrollment into the Continued
Claims System, updating demographics or eligibility information, certifying for benefits or
requesting lost or stolen check forms.
Employment Program Representatives (EPRs), also known as Customer Service
Representatives (CSRs), will access the CCR System via an internal network connection to
respond to customer service inquiries around continued claims, file additional claims, or
adjust existing continued claims.
Managers will access the CCR System via an internal network connection to manage
workflows, manage business rules or monitor and assign workload.
Operations Managers or Program Analysts will access the CCR System via an internal
network connection to generate reports.
Employers will access the CCR System via the Web or IVR to setup or manage Partial and
Work Sharing claims.

1673D445-8846-415B-9B58-82958E8C824D.DOC                                      ADDENDUM 3      APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 15 of 159



Program Analysts will access the CCR System via an internal network connection to
generate fraud reports, publish content to the Web, or process Web correspondence
(correspondence received via the Web).
System Account Administrators will access the CCR System via an internal network
connection to perform continued claims system accounts management.
Training Providers will access the CCR System via the Web or IVR to setup and manage
California Training Benefits.
Based on other States‘ experience it is anticipated that the Employment Development
Department (EDD) will be subject to significant spikes in transaction volume on Sunday
mornings between 9:00am and noon, with 90 percent of Continued claims certifications
being received by close of business on Monday. There is also a yearly spike, the timing of
which depends on weather conditions and is most often seen from November to February
(depending on weather). The CCR System must be able to accommodate these spikes in
business volume.

6C.1.3.3      CCR Use Cases’ Functional Requirements

These requirements will enable Public Customers to manage their account via the Web.
This includes enrolling for on-line services, changing passwords and providing information
necessary to process their continued claims.

6C.1.3.4      Manage Claimant Account via the Internet Use Case Functional
              Requirements
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   82         The System must allow Claimant to view demographics information.          FCTN904
   83         The System must allow Claimant to view continued claims                   FCTN905
              information.
   84         The System must allow Claimant to review eligibility information.         FCTN906
   85         The System must provide the ability for Claimants to login and access     FCTN907
              the system.
   86         The System must secure User ID and password.                              FCTN908
   87         The System must record multiple login attempts and if attempts            FCTN909
              exceed a threshold, create an alarm/notification.
   88         After each failed login attempt, the system must block access to the      FCTN910
              user account for predetermined variable time interval, with the time
              interval increasing with each additional failed login attempt. The
              system configuration must be able to control the time interval, and the
              minimum and maximum value.
   89         If the user is shut out, the System must notify the Claimant of the       FCTN911
              course of action to take.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 16 of 159


                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   90         The System must allow the Claimant to be able to print payment            FCTN912
              history, deductions, total amount received in a defined period of time,
              etc., from the EDD Web site.
   91         The System must be able to display claim-specific (pre-populated with     FCTN913
              Claimant/Claim specific information) forms (e.g. DE 731, 1099G) that
              the Claimant can either download or request to be mailed. (See
              Bidders' Library, Forms folder.)
   92         The System must allow the Claimant to download claim specific             FCTN914
              forms. (See Bidders' Library, Forms folder.)
   93         The System must allow the Claimant to order claim-specific forms to       FCTN915
              be mailed.
   94         The CCR System must not allow a customer who has requested a              FCTN916
              personalized, printed form to re-request the same form until a
              configurable amount of time has passed.
   95         The CCR System must display a configurable message to any                 FCTN917
              customers who have re-requested a personalized, printed form from
              the CCR System within the specified time period.
   96         The CCR System must allow authorized staff to re-send a                   FCTN918
              personalized, printed form to a claimant at any time, regardless of
              whether a form has been recently mailed or not.



6C.1.3.5      Update Online Account Personal Preferences Use Case Functional
              Requirements
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   97         The System must display all of the Claimant‘s current preferences.        FCTN945
   98         The System must allow the Claimant to update any of the personal          FCTN946
              preferences.
   99         The System must display the updated preferences to the Claimant in        FCTN947
              real-time.
   100        The System must generate a notification to the Claimant that the          FCTN948
              personal preferences have been updated.
   101        The System must have the functionality to allow or restrict a             FCTN1292
              claimant's access to any certification channel.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 17 of 159



6C.1.3.6      Update Demographics via the Internet Use Case Functional Requirements
                                                                                                     Bidder
Requirement
                                           Requirement                                   State Use   Agrees
Number
                                                                                                     (Y/N)
   102        The System must support multiple addresses and phone numbers for           FCTN919
              each Claimant.
   103        The System must allow Claimant or CSR to update demographic                FCTN920
              information.
   104        The System must provide address verification rules to ensure that          FCTN921
              address is valid (e.g., validate zip code, street existence).
   105        If the address entered is not valid, the System must capture the           FCTN922
              invalid address and the reason, and post the information in a work
              queue.
   106        In the event of a successful address change, the System must send          FCTN923
              notification of the address changes to both the claimant's new and old
              address.
   107        The System must capture information about transactions that failed to      FCTN924
              meet verification requirements (i.e., detected fraud transactions).
   108        If Claimant is in appeal status and changes their address(es) or           FCTN925
              phone number(s), the System must notify the appropriate Office of
              Appeals.
   109        The System must store the update history including a time stamp,           FCTN926
              who, and reason for each update.
   110        The System must record when a document is downloaded or when               FCTN929
              there is a request for a document to be mailed.
   111        If additional information is required for validation, the System must be   FCTN930
              able to inform the Claimant as to which documents need to be
              submitted.
   112        The System must provide the Claimant with a choice to download             FCTN931
              documents or request documents to be mailed.
   113        The System must be able to create a workflow for documents to be           FCTN932
              mailed.



6C.1.3.7      On-line Enrollment Use Case Functional Requirements
                                                                                                     Bidder
Requirement
                                           Requirement                                   State Use   Agrees
Number
                                                                                                     (Y/N)
   114        The System must enable user to input identification information.           FCTN933
   115        The System must prompt the Claimant to create an on-line User ID           FCTN935
              and password.
   116        The system must create an on-line customer Identity and Profile for        FCTN936
              the Claimant, and store the User ID, basic profile and encrypted
              /hashed credentials in the Directory and store extended claimant
              profile and extended multiple encrypted/hashed authentication factors
              in UIMOD Repository.

1673D445-8846-415B-9B58-82958E8C824D.DOC                                                 ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 18 of 159


                                                                                                  Bidder
Requirement
                                           Requirement                                State Use   Agrees
Number
                                                                                                  (Y/N)
   117        The System must prompt the Claimant to establish a personal             FCTN937
              profile/preferences.
   118        The System must prompt the Claimant to configure mail                   FCTN938
              correspondence preference (e.g., electronic vs. paper mail).
   119        The System must prompt the Claimant to select certification options     FCTN939
              (electronic, IVR, or paper mail).
   120        The System must provide the Claimant the option to block access to      FCTN941
              any channel.
   121        The System must allow the Claimant to select language preference.       FCTN942
   122        The System must support English and Spanish, and be extensible for      FCTN943
              future support of other (including double byte character) languages
              when required by the Dymally-Alatorre Act.
   123        The System must notify the Claimant via U.S. Postal Service that the    FCTN944
              on-line account was established.
   124        The System must not allow a claimant with an existing username and      FCTN1308
              password to create a duplicate username and password.
   125        The System must allow user password characteristics to be               FCTN1309
              configurable by channel, including, but not limited to, the number of
              characters required, and the types of characters required.



6C.1.3.8      Change Password Use Case Functional Requirements
                                                                                                  Bidder
Requirement
                                           Requirement                                State Use   Agrees
Number
                                                                                                  (Y/N)
   126        The System must allow user to change password.                          FCTN949
   127        The System must prompt the Claimant to enter his/her new password       FCTN950
              multiple times to ensure that it is correctly entered.
   128        The System must describe allowable password characteristics.            FCTN951
   129        The System must check the password for allowable characteristics        FCTN952
              and prompt the Claimant if password constraints are not followed.
   130        The System must store the new password and update the customer          FCTN953
              configuration.
   131        The System must provide real-time confirmation that the password has    FCTN954
              been changed.
   132        The System must notify the Claimant via U.S. Postal Service that        FCTN955
              password change has been made.
   133        The System must integrate with the EDD security system for password     FCTN956
              change.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                              ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 19 of 159



6C.1.3.9      Forgotten User ID and/or Password Use Case Functional Requirements
                                                                                                   Bidder
Requirement
                                           Requirement                                 State Use   Agrees
Number
                                                                                                   (Y/N)
   134        The System must allow the user to enter a hint to get a password         FCTN957
              reminder.
   135        The System must authenticate user using randomly changing                FCTN958
              scripts — based on Claimant prerecorded questions and answers.
   136        The System must generate a temporary password for a Claimant who         FCTN960
              has forgotten their password.
   137        The System must store the new password and update the customer           FCTN961
              configuration.
   138        The System must provide real-time confirmation that the password         FCTN962
              was successfully reset.
   139        The System must notify the Claimant via U.S. Postal Service that the     FCTN963
              password has been reset.
   140        Requirement Deleted                                                                   N/A



6C.1.3.10     Update Eligibility Information Use Case (Self-Service) Functional Requirements
                                                                                                   Bidder
Requirement
                                           Requirement                                 State Use   Agrees
Number
                                                                                                   (Y/N)
   141        Upon successful login, the System must display claim and continued       FCTN964
              claims information.
   142        The System must accept an update to one or more elements of the          FCTN965
              eligibility information, within business rules constraints.
   143        For verification requirements associated with questions, the System      FCTN966
              must prompt user for the answer to each question and capture the
              user‘s response.
   144        For verification requirements associated with documents, the System      FCTN967
              must inform user of the documents that must be supplied for
              verification and information regarding how to convey the documents
              to EDD.
   145        For verification with other sources, the System must inform user that    FCTN968
              this verification will be undertaken.
   146        The System must be able to create workflows to collect and validate      FCTN969
              additional information. There are two main scenarios for the workflow:
              1) An external system interface is down, or
              2) EDD staff needs to intervene and collect/verify additional
              information.
   147        The System must maintain a transaction log for changes to eligibility    FCTN970
              information which includes source and reason.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                               ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 20 of 159


                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   148        The System must recognize information updates that require external       FCTN971
              verification (e.g., SAVE) and route the information to a work queue.
   149        The System must retain external verification information.                 FCTN972
   150        For verification with external verification sources, the System must be   FCTN973
              able to manage a workflow which may involve email or other types of
              verification requests to the applicable external source(s).
   151        The System must capture information about transactions that failed to     FCTN974
              meet verification requirements (i.e., detected fraud transactions).
   152        For any failed transaction, the System must create a workflow to          FCTN975
              handle the failed transaction.
   153        The System must provide real-time confirmation of the updates.            FCTN976
   154        The System must notify the Claimant of the updates if needed.             FCTN977
   155        For any detected eligibility issues, the System must send a request       FCTN978
              for determination interview appointment to the Unemployment
              Insurance Scheduling System (UISS).



6C.1.3.11     Request Lost or Stolen Check Forms Use Case Functional Requirements
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   156        The System must prompt the Claimant for the condition of the lost or      FCTN1019
              stolen check.
   157        The System must pre-populate the forms with Claimant specific             FCTN1020
              information.
   158        The System must record warrant numbers, week ending dates and             FCTN1021
              reason for all outgoing forms.
   159        If the Claimant is accessing the form via the Web, the System must        FCTN1022
              prompt the Claimant to determine if they want to download the form
              directly.
   160        The System must allow the Claimant to download the form in a read-        FCTN1023
              only universal format (such as PDF).
   161        If the Claimant has requested the form to be mailed via USPS, the         FCTN1024
              System must export a print request to ODPD (see ODPD interface
              section for details of the ODPD interface).
   162        The System must keep a history of provided forms.                         FCTN1025




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 21 of 159



These requirements will enable EPRs (CSRs) to process continued claims and respond to
inquiries about continued claims or adjust previously processed continued claims. This
includes answering questions, updating demographics or continued claims information,
resetting passwords, filing additional claims or processing adjustments.

6C.1.3.12     Customer Service Use Case Functional Requirements
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   163        If the Claimant has been authenticated in the IVR, the System must        FCTN1026
              provide that authentication information to the CSR.
   164        If the Claimant has been authenticated in the IVR, the System must        FCTN1027
              populate the CSR‘s screen with IVR and claim data.
   165        If the Claimant has not been authenticated in the IVR, the System         FCTN1028
              must prompt the CSR to authenticate the Claimant.
   166        The System must provide search capabilities and display the search        FCTN1029
              results by: Claimant by SSN, ECN or assigned Claimant unique UI
              identifier; Claimant by Name (phonetic search); Claimant by Address;
              Claimant by Employer; Employer Corporate Name (phonetic search).
   167        The System must be able to display a list of employees by Employer        FCTN1030
              to authorized staff where the Employer has reported wages for that
              employee.
   168        The System must be able to display a list of employees by Employer        FCTN1031
              where the Employer has been identified as a last Employer.
   169        The System must be able to display a summary by claim depicting the       FCTN1032
              disposition of each week in a Claimant‘s benefit year.
   170        The System must be able to display detailed information for a             FCTN1033
              selected week showing details of the check calculation (basic amount
              to net) including any adjustments or the non-compliance conditions
              that prevented payment or led to the establishment of an
              overpayment.
   171        The System must be able to display for a selected week a Claimant‘s       FCTN1034
              specific eligibility requirements and associated responses.
   172        The System must be able to display detailed demographic information       FCTN1035
              for each Claimant.
   173        The System must be able to display detailed information (e.g., status,    FCTN1036
              balance, begin date, end date, general eligibility information) on each
              claim. (General eligibility information includes work search, full vs.
              part time employment history and school status.)
   174        The System must be able to display a history of payments and              FCTN1037
              detailed information in each payment including the weeks associated
              with each payment and any adjustments such as cancellations and
              transfers.
   175        The System must be able to cancel authorization of a payment if           FCTN1038
              check has not been issued.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 22 of 159


                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   176        The System must be able to view and print UI payment information          FCTN1039
              and range of payment(s) in a particular year (benefit, calendar and
              tax years).
   177        The System must store customer contact information.                       FCTN1040



6C.1.3.13     Update Eligibility Information Use Case (CSR) Functional Requirements
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   178        Using the Claimant‘s identification information (e.g. unique UI           FCTN1042
              identifier) provided by the CSR/IVR, the System must display the claim
              and continued claims information.
   179        For verification requirements associated with questions, the System       FCTN1044
              must prompt user for the answer to each question and capture the
              user‘s response.
   180        For verification requirements associated with documents, the System       FCTN1045
              must inform user of the documents that must be supplied for
              verification and information regarding how to convey the documents to
              EDD.
   181        For verification with other sources, the System must inform user that     FCTN1046
              this verification will be undertaken.
   182        The System must be able to create workflows to collect and validate       FCTN1047
              additional information.
   183        The System must maintain a transaction log for changes to eligibility     FCTN1048
              information which includes source and reason.
   184        The System must recognize information updates that require external       FCTN1049
              verification (e.g., SAVE) and send the information to a work queue to
              be managed.
   185        The System must record verification responses from external sources       FCTN1050
              (e.g., SAVE).
   186        For verification with external verification sources, the System must be   FCTN1051
              able to manage a workflow which may involve e-mail or other types of
              verification requests to the applicable external source(s).
   187        The System must capture information about transactions that failed to     FCTN1052
              meet verification requirements (i.e., detected fraud transactions).
   188        For any failed transaction, the System must create a workflow to          FCTN1053
              handle the failed transaction.
   189        The System must provide real-time confirmation of the updates.            FCTN1054
   190        The System must notify the Claimant of the updates if needed.             FCTN1055




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 23 of 159



6C.1.3.14     Cancel or Reschedule Appointment Use Case Functional Requirements
                                                                                                  Bidder
Requirement
                                           Requirement                                State Use   Agrees
Number
                                                                                                  (Y/N)
   191        The System must allow the CSR to view scheduling/appointment            FCTN1056
              information.
   192        The System must allow the CSR to cancel the appointment.                FCTN1057
   193        The System must allow the CSR to request a new appointment to be        FCTN1058
              scheduled.
   194        The System must record the reason for the appointment change or         FCTN1059
              cancellation.
   195        The System must be able to send notification of appointment changes     FCTN1060
              to Claimant.



6C.1.3.15     Reset Customer Password Use Case Functional Requirements
                                                                                                  Bidder
Requirement
                                           Requirement                                State Use   Agrees
Number
                                                                                                  (Y/N)
   196        The system must have the functionality to generate a temporary one-     FCTN1061
              time password and send it to the user account contact method.
   197        The system must be able to expire the temporary one time password if    FCTN1062
              not reset by the customer after a pre-defined and configurable time
              period.
   198        The system must automatically notify the Claimant instructions          FCTN1063
              describing how to sign in using the temporary one time password as
              well as how to create a permanent password.



6C.1.3.16     Additional Claim Use Case Functional Requirements
                                                                                                  Bidder
Requirement
                                           Requirement                                State Use   Agrees
Number
                                                                                                  (Y/N)
   199        The System must be able to capture data including last Employer,        FCTN1064
              Employer type (e.g., Federal/non-Federal) separation information, and
              last day of work.
   200        The System must prompt the user entering new last Employer with list    FCTN1065
              of previous Employers to allow selection from a list.
   201        The System must be capable of reporting the separation information,     FCTN1066
              number of Additional Claims, etc., for the purposes of Department of
              Labor audits and quality assurance.
   202        The System must validate all fields and validate combinations of        FCTN1067
              answers to ensure consistency.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                              ADDENDUM 3           APRIL 8
 OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
 UIMOD PROJECT                                                     SECTION 6C — PAGE 24 of 159


                                                                                                     Bidder
 Requirement
                                               Requirement                               State Use   Agrees
 Number
                                                                                                     (Y/N)
    203         The System must perform validation on all fields on the additional       FCTN1068
                claim as well as validation between combinations of answers to ensure
                they are logically consistent. This includes validation to prevent
                premature filing.
    204         If the Claimant‘s separation reason raises an eligibility issue, the     FCTN1069
                System must invoke the process for scheduling a determination
                interview.
    205         The System must supply the Claimant with information about the           FCTN1070
                certification process.
    206         If appropriate, the System must notify the Employer of the Claimant‘s    FCTN1071
                statements (to give the Employer the ability to protest the claim).
    207         The System must recognize when not to send a notice to the               FCTN1072
                Employer based on a set of rules, (e.g., Federal Employer, partial
                Employer).



 6C.1.3.17       Update Certification Information Use Case Functional Requirements
                                                                                                     Bidder
Requirement
                                              Requirement                                State Use   Agrees
Number
                                                                                                     (Y/N)
   208         The System must display continued claim information given SSN, ECN        FCTN1073
               or assigned EDD Account number.
   209         The System must allow the Adjustor to obtain detailed claim(s)            FCTN1074
               information.
   210         The System must accept an update to one or more elements of               FCTN1075
               Certification information within security constraints.
   211         The System must be able to store original certification submission and    FCTN1076
               the corrected/updated certification submission and maintain a complete
               history.
   212         The System must store the reason for the change and the User ID of        FCTN1077
               the person who made the update.
   213         Depending on which elements are changed, the System must specify          FCTN1078
               and prompt the Adjustor for additional information.
   214         The System must present the Adjustor with information on updated          FCTN1079
               continued claims.
   215         When the agent saves any changes, the System must re-evaluate the         FCTN1080
               status of the updated continued claim.
   216         After the continued claim has been re-evaluated following a change, the   FCTN1081
               System must display the results of the updated certification.




 1673D445-8846-415B-9B58-82958E8C824D.DOC                                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 25 of 159



6C.1.3.18     Capturing Unscannable Data Use Case Functional Requirements
                                                                                                       Bidder
Requirement
                                            Requirement                                    State Use   Agrees
Number
                                                                                                       (Y/N)
   217        The System must identify and display continued claims exceptions.            FCTN1082
   218        The System must sort and prioritize the exception work queue                 FCTN1083
              according to business rules (e.g., FPTL, age, issues, and reasons for
              exception).
   219        The System must allow Adjustors to access continued claims in a              FCTN1084
              particular work queue.
   220        The System must display the next continued claim in the work queue           FCTN1085
              automatically.
   221        The System must allow Adjustors to navigate from screen to screen            FCTN1086
              without having to reenter query parameters in order to update
              information.
   222        The System must present Adjustor with results of the updated                 FCTN1087
              information.
   223        If there are no unmet eligibility requirements, the System must store        FCTN1088
              updated information and the action that was taken to resolve the
              exception (for quality control).
   224        If there are no unmet eligibility requirements, the System must forward      FCTN1089
              the continued claim for payment.
   225        If unmet eligibility requirements exist and a determination interview is     FCTN1090
              required, the System must store the updated information and request
              a determination appointment from UISS.
   226        If unmet eligibility requirements exist and the required information is      FCTN1286
              not available and no definite eligibility issues exist, the System must
              store whatever information is present, along with the actions taken by
              the adjustor to resolve the omissions, and provide instructions to the
              Claimant regarding how to proceed.
   227        The System must capture the originally scanned information, all              FCTN1287
              updated information, the reason(s) why the information was changed,
              and how the adjustor obtained the updated information.
   228        If after all unscannable information is updated, barriers to payment still   FCTN1288
              exist that would also route to an adjustor, the system must return that
              workload item to the same adjustor in lieu of assigning it to a different
              work queue/adjustor.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                   ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 26 of 159



6C.1.3.19     Processing Work Queues Use Case Functional Requirements
                                                                                                  Bidder
Requirement
                                           Requirement                                State Use   Agrees
Number
                                                                                                  (Y/N)
   229        Based on the selected workload item, the System must display claim      FCTN1091
              and continued claims information.
   230        The System must allow an Adjustor to display a work queue of items      FCTN1092
              which require validation before eligibility can be updated.
   231        The System must allow an Adjustor to select an item on the work         FCTN1093
              queue for processing.
   232        If work cannot be completed, the System must allow the Adjustor to      FCTN1094
              return the work to work queues for later processing.
   233        The System must present all barriers to payment to the same adjustor    FCTN1289
              (in lieu of assigning it to a different work queue/adjustor).



6C.1.3.20     Insurance Accounting Division (IAD) Service Request Use Case
              Functional Requirements
                                                                                                  Bidder
Requirement
                                           Requirement                                State Use   Agrees
Number
                                                                                                  (Y/N)
   234        The System must capture a request sent to IAD, including claim(s) and   FCTN1095
              continued claim(s) affected, date sent, follow-up date, etc.
   235        The System must electronically send a request to IAD.                   FCTN1096
   236        The System must record the IAD responses.                               FCTN1097
   237        The System must route the IAD response to an adjustor work queue        FCTN1098
              as determined by business rules.
   238        The System must allow the user to enter the outcome of a request        FCTN1099
              sent to IAD (e.g., completed, cancelled, modified with explanation).


These requirements will enable the System to calculate benefit payment amounts and
initiate payment distribution.

6C.1.3.21     Calculate Payment Use Case Functional Requirements
                                                                                                  Bidder
Requirement
                                           Requirement                                State Use   Agrees
Number
                                                                                                  (Y/N)
   239        The System must calculate payment amount the Claimant is entitled to    FCTN1100
              receive based on weekly benefit amount.
   240        The System must calculate and apply deductions using established        FCTN1101
              hierarchy rules. Examples of deductions: Wages and illness; Child
              support; Overpayment; Federal income tax (can be changed weekly
              by Claimant); Pension; Worker‘s compensation; and, Work Sharing
              (percentage of amount unemployed).


1673D445-8846-415B-9B58-82958E8C824D.DOC                                              ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 27 of 159


                                                                                                 Bidder
Requirement
                                          Requirement                                State Use   Agrees
Number
                                                                                                 (Y/N)
   241        The System must allow wage and Federal tax withholding deduction       FCTN1102
              calculations to be parameterized.
   242        The System must allow wage calculation and Federal tax withholding     FCTN1103
              deductions parameters to be changed without application
              development.
   243        The System must detect if check is a replacement or adjustment         FCTN1104
              check.
   244        If check is an adjustment check, the System must account for payment   FCTN1105
              (and associated deductions) already made on behalf of the Claimant.
   245        If check is a replacement check, the System must account for           FCTN1106
              payments (and associated deductions) already made on behalf of the
              Claimant.



 6C.1.3.22 Initiate Payment Distribution Use Case Functional Requirements
                                                                                                 Bidder
Requirement
                                          Requirement                                State Use   Agrees
Number
                                                                                                 (Y/N)
   246        The System must be able to accumulate payments for multiple weeks      FCTN1107
              calculated (See Appendix C - CCR Use Cases, Calculate Payment).
   247        The System must update the databases.                                  FCTN1108
   248        The System must be able to schedule payment (by posting payment        FCTN1109
              to a work queue) to be disbursed by appropriate payment
              authority/systems, (e.g., ODPD).
   249        The Systems must be able to generate multiple disbursements based      FCTN1110
              on the amount payable (to minimize fraud associated with large
              amounts payable).
   250        The System must be able to check all disbursements for anomalies       FCTN1316
              and route any anomalous disbursements for additional approvals
              prior to processing disbursement.
   251        The System must allow parameters for disbursements to be changed       FCTN1317
              using a business rules framework.



6C.1.3.23     Replacement Check Use Case Functional Requirements
                                                                                                 Bidder
Requirement
                                          Requirement                                State Use   Agrees
Number
                                                                                                 (Y/N)
   252        The System must be able to record when a check is cancelled, by        FCTN1111
              whom, and for what reason.
   253        The System must record when a replacement check is authorized.         FCTN1112
   254        In case a fraud event is detected, the System must generate a fraud    FCTN1113
              alert (i.e. a notification to a fraud analyst).


1673D445-8846-415B-9B58-82958E8C824D.DOC                                             ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 28 of 159




These requirements will enable staff to update eligibility information based on priority
judgments from a third party and to allow the system to process any affected continued
claims based on the updated information.

6C.1.3.24     Process Decisions Use Case Functional Requirements
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   255        The System must capture the time frame affected by the process           FCTN1114
              decision on the eligibility of the claim and/or certification.
   256        Using the time frame of the eligibility decision, the System must        FCTN1115
              present the affected weeks of the claim.
   257        The System must capture and store the results of the eligibility         FCTN1116
              decision for the claim and/or certification.
   258        The System must present the results of the eligibility decision on the   FCTN1117
              affected week(s) to the EPR immediately after the decision is entered.



6C.1.3.25     Manage Workflow Use Case Functional Requirements
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   259        The System must allow a Workflow Administrator to administer             FCTN1118
              employee roles.
   260        The System must allow all Workflow Administrators to view the            FCTN1119
              current roles of all employees.
   261        The System must allow Central Office Workflow Administrators to          FCTN1120
              manage the enterprise.
   262        The System must allow Field Office Workflow Administrators to            FCTN1121
              manage their office‘s staff.
   263        The System must allow Workflow Administrator to assign work              FCTN1122
              queues to roles or individuals.
   264        The System must maintain a history of all changes to employee            FCTN1123
              profile (including who changed and why).



6C.1.3.26     Manage Business Rules Use Case Functional Requirements
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   265        The System must have a rules engine for business logic.                  FCTN1124
   266        The System must be able to simulate and model the business and           FCTN1125
              system impact of rule changes.

1673D445-8846-415B-9B58-82958E8C824D.DOC                                               ADDENDUM 3            APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                                 RFP OSI 7100-181
UIMOD PROJECT                                                      SECTION 6C — PAGE 29 of 159


                                                                                                          Bidder
Requirement
                                             Requirement                                      State Use   Agrees
Number
                                                                                                          (Y/N)
   267        The simulation and modeling of rules changes for testing purposes               FCTN1126
              must not impact the production environment.
   268        The System must be able to allow rules to be changed without                    FCTN1127
              changes to application code.



6C.1.3.27     Monitor and Assign Workload Use Case Functional Requirements
                                                                                                          Bidder
Requirement
                                             Requirement                                      State Use   Agrees
Number
                                                                                                          (Y/N)
   269        The System must provide reporting capability to monitor workload                FCTN1128
              (e.g., by individual, group, site and department activities, including
              number of claims processed, number of claims passed a specified
              due date, Adjustor backlog).
   270        The System must have a ―dashboard‖ to display current operating                 FCTN1129
              conditions in the workload queues.
   271        The System must allow setting different authorization levels                    FCTN1130
              depending on the type of routing rule modification requested (e.g.,
              local vs. multiple centers, temporary vs. permanent).
   272        The System must allow Manager to add/remove work queues.                        FCTN1131
   273        The System must allow Manager to assign/remove staff to work                    FCTN1132
              queues.
   274        The System must recognize when first payments are obstructed and                FCTN1133
              notify management of the potential to miss the FPTL performance
              measurement.
   275        The System must allow EDD Managers to establish thresholds for                  FCTN1134
              time sensitive activities, related notifications/ticklers, and for triggering
              associated workflow.
   276        The System must generate messages after a pre-defined and                       FCTN1135
              configurable time period has elapsed, and trigger a workflow for
              actions.
   277        The System must be able to manage multiple work queues.                         FCTN1136
   278        The System must be able to route claims with exceptions to different            FCTN1137
              work queues.
   279        The System must allow Managers to associate staff/Adjustors with                FCTN1138
              one or multiple workload queues.
   280        An employee must be able to route work to another work queue                    FCTN1139
              (employee based on preset routing conditions).
   281        The System must monitor the work queues and based on                            FCTN1140
              configurable parameters, the system must be able to alarm a
              Manager(s), reroute/escalate work, or perform other tasks based on
              specified conditions occurring.



1673D445-8846-415B-9B58-82958E8C824D.DOC                                                      ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 30 of 159


                                                                                                   Bidder
Requirement
                                           Requirement                                 State Use   Agrees
Number
                                                                                                   (Y/N)
   282        The System must allow the Manager to reallocate workload between         FCTN1141
              centers/work queues.



These requirements will enable Employers to submit certifications for Partial and Work
Sharing programs to verify that their employees‘ hours have been reduced. In addition, staff
will be able to enter and update Partial and Work Sharing certification information received
through the paper process.

6C.1.3.28     Setup and Manage Partials and Work Sharing Use Case Functional
              Requirements
                                                                                                   Bidder
Requirement
                                           Requirement                                 State Use   Agrees
Number
                                                                                                   (Y/N)
   283        The System must be able to associate Employers with Claimants for        FCTN1160
              Work Sharing and partials.
   284        The System must display a list of the Employer‘s employees on the        FCTN1161
              partial/Work Sharing Program.
   285        The System must allow Employers to maintain their list of employees      FCTN1162
              (add, update or delete).
   286        The System must allow the Employer to update the employee, week,         FCTN1163
              and wages earned, etc., and submit the information (via the Web
              entry) to EDD.
   287        The System must notify Employers automatically when required             FCTN1164
              (e.g., benefit reduction, Work Sharing contract has expired).
   288        The system must allow authorized staff to enter and update an            FCTN1313
              Employer‘s list of Partial and Work Sharing employees and continued
              claim certification information.



These requirements will enable Program Analysts to create fraud detection reports and
perform fraud analysis.

6C.1.3.29     Fraud Condition Detected Use Case Functional Requirements
                                                                                                   Bidder
Requirement
                                           Requirement                                 State Use   Agrees
Number
                                                                                                   (Y/N)
   289        The System must enable users to query and perform drill-down             FCTN1165
              analysis on fraud detection information.
   290        The System must allow fraud analysts to evaluate multiple data           FCTN1166
              sources while performing their analysis.
   291        The System must provide the functionality to identify the data that is   FCTN1167
              most predictive of fraud patterns.


1673D445-8846-415B-9B58-82958E8C824D.DOC                                               ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 31 of 159


                                                                                                      Bidder
Requirement
                                            Requirement                                   State Use   Agrees
Number
                                                                                                      (Y/N)
   292        The System must provide the functionality to monitor the information        FCTN1168
              in real-time and in batch for pre-set fraud conditions.
   293        The System must be able to route potential fraud data to a work             FCTN1169
              queue.
   294        The System must provide the Fraud Analyst with on-line functionality        FCTN1170
              to document potential fraud.
   295        The System must provide the Fraud Analyst with on-line functionality        FCTN1171
              to submit the potential fraud information to the Investigation Division.
   296        The System must be able to report on all detected fraud including           FCTN1172
              total number of fraud events by type and amount.
   297        The System must be able to list and report fraud events.                    FCTN1173
   298        The System must allow the Fraud Analyst to drill down on each fraud         FCTN1174
              event.



These requirements will enable Program Analysts to publish content to the Web.

6C.1.3.30     Publishing Content Use Case Functional Requirements
                                                                                                      Bidder
Requirement
                                            Requirement                                   State Use   Agrees
Number
                                                                                                      (Y/N)
   299        Mandatory/Optional                                                          FCTN1175
              The System must enable UI business subject matter experts to publish
              content to Web site without IT intervention.
   300        Mandatory/Optional                                                          FCTN1176
              The System must implement a workflow and approval process for
              publishing content to the Web.
   301        Mandatory/Optional                                                          FCTN1177
              The System must ensure consistency of content between Web and
              IVR environments.
   302        Mandatory/Optional                                                          FCTN1178
              The System must allow multiple staff to collaborate in the design of
              content.
   303        Mandatory/Optional                                                          FCTN1179
              The System must maintain a configurable amount of history of all Web
              content information contained on the site (e.g., date, revision, Author).
              Mandatory/Optional                                                          SUPP864
   303a       The Web Content Management System must be housed in EDD
              facilities.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                  ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 32 of 159



These requirements will enable Program Analysts and/or EPRs to process customer
correspondence via the Web.

6C.1.3.31     Web Correspondence Use Case Functional Requirements
                                                                                                     Bidder
Requirement
                                           Requirement                                   State Use   Agrees
Number
                                                                                                     (Y/N)
   304        The System must attempt to satisfy customer inquiry with Frequently        FCTN1180
              Asked Questions (FAQ) prior to allowing option to submit Web
              correspondence.
   305        The System must have the capability to link to other areas of the EDD      FCTN1181
              Web.
   306        The System must notify Web correspondence analyst(s) when items            FCTN1182
              are available to be worked.
   307        The System must capture responses to correspondence.                       FCTN1183
   308        The System must capture the response method (e.g., email or USPS).         FCTN1184
   309        The System must initiate the response release.                             FCTN1185
   310        If response is via e-mail, the System must send response from generic      FCTN1186
              e-mail ID (not allowing personal analyst‘s e-mail id as return
              ―address‖).
   311        The System must allow rules to dictate how work is routed to the work      FCTN1187
              queues.
   312        The System must capture and store data regarding the                       FCTN1188
              correspondence (e.g., count, age, question, question category).
   313        The System must allow for escalation of claimant correspondence            FCTN1189
              when it is unanswered for a configurable amount of time.
   314        The System must provide a report that shows the question category,         FCTN1190
              question and related information for the purpose of identifying question
              and answer candidates for addition to the UI frequently asked
              questions (FAQ) pages.
   315        The System must provide the ability to add new categories of question      FCTN1310
              types for customers to select when submitting a question.
   316        The System must provide the ability to add new questions and               FCTN1311
              answers to the UI FAQ page.
   317        The system must allow the use of templates to publish Web content.         FCTN1314




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                 ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 33 of 159



These requirements will enable Account Administrators to administer accounts. This
includes establishing or revoking User IDs and creating or suspending an account.

6C.1.3.32     Continued Claims Systems Account Management Use Case Functional
              Requirements
                                                                                                   Bidder
Requirement
                                           Requirement                                 State Use   Agrees
Number
                                                                                                   (Y/N)
   318        The System must log all account administration.                          FCTN1191
   319        The System must notify supervisor of all account administration          FCTN1192
              activities.
   320        The System must report daily on accounts that have not been used for     FCTN1193
              a configurable number of days.
   321        The System must automatically disable access to accounts that have       FCTN1194
              not been used for over a configurable number of days.
   322        The System must allow a System Account Administrator to manage           FCTN1195
              accounts.
   323        The System must track and log all account related information.           FCTN1197
   324        The System must be able to report on all account related information     FCTN1198
              and activities.


These requirements will enable Training Providers to submit certifications that verify a
Claimant is in satisfactory training status.

6C.1.3.33     Setup and Manage CTB Use Case Functional Requirements
                                                                                                   Bidder
Requirement
                                           Requirement                                 State Use   Agrees
Number
                                                                                                   (Y/N)
   325        The System must be able to associate Training Providers with             FCTN1200
              Claimants.
   326        The System must display a list of the CTB enrolled students for each     FCTN1201
              Training Provider.
   327        The System must identify the period for which the Claimant is eligible   FCTN1202
              for certification.
   328        The System must allow the Training Provider and authorized staff to      FCTN1203
              update the Claimant‘s attendance records for each week that the
              Claimant is eligible for certification.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                               ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                        RFP OSI 7100-181
UIMOD PROJECT                                             SECTION 6C — PAGE 34 of 159



6C.2 SYSTEM INTERFACES
The UIMOD replaces a portion of the UI System (UIS) that is currently used for UI. The
System must be integrated with the UIS system (which will continue to be used for initial
claims, adjudications and customer service). The System must also be integrated with
multiple other systems that are also currently integrated with UIS.
The System depends on information that originates in external systems, some of which have
shorter hours of availability (than the 24 X 7 availability expected for CCR). The System
must be able to function even when one or more of these external systems are unavailable.
In this section the interfaces are defined as being external to this Project and outside of the
Contractor‘s control. For example, the CCR System will need to transfer data to the Data
Warehouse, but this is not considered an external interface, as the Data Warehouse is
under the Contractor‘s control. In contrast, retrieving data from the UIS will require an
external interface as it is an external system that is not controlled by the UIMOD Project.
The UIMOD Project requires one set of interfaces for all channels (Web, IVR, intranet, smart
client). This section provides the following:
     1. Overview of External System Dependencies: An overview of external systems that
        must be integrated with the CCR System.

     2. Global Interface Requirements: Global requirements that apply to all interfaces
        (unless specified otherwise in each individual interface‘s requirements).

     3. Detailed Integration Requirements: Detailed Integration requirements which must
        be met by the integrator(s).




1673D445-8846-415B-9B58-82958E8C824D.DOC                                           ADDENDUM 3     APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 35 of 159




6C.2.1          Overview of External System Dependencies

6C.2.1.1        UIMOD System Dependencies Overview
        Name of System                                 Overview of System Functionality
Activity Calendar and Event     A scheduling system used by Job Service Staff to schedule appointments and
Scheduler (ACES)                workshops, and post attendance results. (Uses an AIX, Informix database)
Base Wage Database              A DB2 database that contains quarterly employer, employee, and wage
(BWDB); also referred to as     information used for calculating Unemployment Insurance (UI)/Disability
the Base Wage File (BWF)        Insurance (DI) benefits. Also contains tables to support SSN/name verification.
                                A collection of applications used to process accounting of Unemployment
                                Insurance and Disability Insurance benefit payments and overpayments. The
Benefit Accounting System
                                BAS provides for tracking of disbursement of funds to other entities,
(BAS)
                                reconciliation of bank accounts, posting payment transactions to Claimant
                                overpayments, etc. The BAS uses the SCDB as its primary data store.
                                A Web-based system where job seekers can enter their resumes and
                                employers enter job opening information. The system matches job seekers to
California Job Opening
                                suitable job openings based on skills and job requirements. Unemployment
Browser System (CalJOBS)
                                Insurance Claimants may be required to enter a resume in CalJOBS as part of
                                their job search requirements. (Uses an AIX, Informix database)
                                A collection of applications used to process and maintain Disability Insurance
Disability Insurance System     claims. The DIS uses the SCDB as its primary store and shares some data and
(DIS)                           processes with the Unemployment Insurance System. The DIS Automation
                                Project Phase III will be upgrading the DIS.
                                A Web-based customer service tool that allows customers to access answers to
EDDCOMM                         frequently asked questions or to electronically submit questions, comments or
                                complaints to different EDD program areas. (Uses SQL server)
                                Area office that schedules appeal hearings with an administrative law judge
                                when a Claimant or employer files an appeal to a Department ruling or
Office of Appeals (OAP)
                                determination of eligibility. The OAP also issues the judge's decision to all
                                interested parties. (Uses a VSAM file)
Office of Documents,
                                The EDD print facility located in West Sacramento that prints and mails benefit
Publications and Distribution
                                checks and EDD forms. 'Also referred to as ‗West Sac'.
(ODPD)
Program Activity Support        A system used by Job Service staff to record services provided to clients.
System (PASS)                   (Uses an AIX, Informix database)
                                An IDMS database containing UI and DI information including weekly
Single Client Database
                                certification and payment information. The term is also used loosely to refer to
(SCDB)
                                the CICS applications that use the SCDB.
                                The TAS is used to account for monies (taxes and withholdings) sent in by
                                employers. It contains employer information such as employer name, employer
Tax Accounting System (TAS)
                                account number (tax ID number), and address. The TAS utilizes an IDMS
                                database.
                                The 1099 system calculates taxable UI, Paid Family Leave (PFL) and DI
Taxable Unemployment
                                benefits paid to a claimant for a calendar year, generates the Form 1099G
Compensation System (1099)
                                ―Report of Taxable Unemployment Compensation Payments for ____ Tax Year
Tax Year
                                to the claimant and submits a report to the Internal Revenue Service.


1673D445-8846-415B-9B58-82958E8C824D.DOC                                                   ADDENDUM 3              APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                        RFP OSI 7100-181
UIMOD PROJECT                                             SECTION 6C — PAGE 36 of 159



      Name of System                               Overview of System Functionality
                           A system that allows staff to schedule appointments with claimants to resolve
Unemployment Insurance     questions regarding claim eligibility. The UISS is an MVS/CICS/COBOL
Scheduling System (UISS)   application running on a DB2 database. This system is a target for a redesign to
                           another platform.
                           A collection of applications used to process and maintain Unemployment
Unemployment Insurance
                           Insurance claims. The UIS uses the SCDB as its primary data store. The
System (UIS)
                           continued claim process is currently part of UIS.
                           An intranet system currently under development that will provide
Web-Based Claim Filing     Unemployment Insurance staff with Web based tools for filing initial
(WBCF)                     Unemployment Insurance claims. The CCR System will utilize data collected by
                           WBCF.
                           A system used to process and maintain wage information reported by
                           employers and used for calculating UI and DI benefits. The system also
Wage Record System (WGS)
                           processes social security number verification information. The WGS uses the
                           BWDB as its primary data store.
                           An automated system used to identify Unemployment Insurance Claimants who
                           are likely to exhaust their UI benefits and provide them with job search
Worker Profiling and
                           assistance. Claimants selected to participate are referred to various workshops
Reemployment Services
                           and may be required to complete additional activities. A Claimant may be
(Profiling)
                           disqualified from receiving UI benefits for failure to participate in profiling
                           activities. The Profiling system utilizes a DB2 database.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                             ADDENDUM 3               APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 37 of 159



6C.2.1.2       Interface Complexity Definition

In order to assist the Contractor in gaining an understanding to the complexity involved in
the interface, each interface is classified based on our preliminary assessment of
complexity.
  Complexity                                                 Definition
Simple           Two (2) applications (fewer than 50 data elements/fields) and flat message structure/layout.
                        One source — One target application.
                        Minimal data stored and manipulated in the Integration layer.
                        No look-up tables in the integration layers.
                        No business rules in the integration layer.
Moderate                Two (2) or more applications, fewer than 50 data elements (fields) or hierarchical
                         message structure/layouts.
                        Typically one or more sources for back-end and single source for target end.
                        Some business rules (edits) in the integration layer — Maybe some lookup and
                         translation tables but not extensive.
Complex                 Multiple applications (more than two (2) source system), more than 50 data elements
                         (fields). Involves the transformation of data that must move from one hierarchical
                         format to another hierarchical format.
                        Significant set of business rules and edits in the Integration layer including extensive
                         lookup tables and validation rules.
                        Data stored in Integration layer and multiple passes through the data to analyze and
                         transform the data and organize data.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                   ADDENDUM 3               APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 38 of 159




6C.2.2        Global Interface Requirements

This section gives the global requirements that are applicable to all interfaces within the
CCR System.

6C.2.2.1      Global Interface Requirements
                                                                                                      Bidder
Requirement
                                           Requirement                                    State Use   Agrees
Number
                                                                                                      (Y/N)
   329        All interfaces must be maintainable through commercially available          IFACE7
              tools.
   330        All interfaces must be maintainable by EDD personnel.                       IFACE8
   331        Each interface must have the ability to specify how many retries must       IFACE27
              be performed, and what the interval between retries, before the
              interface attempt fails.
   332        In the event of failure, each interface must have the ability to generate   IFACE28
              an Event Log record message.
   333        All access to RDBMS data sources that are external to the CCR               IFACE29
              System, but internal to EDD, must be through views, in order to
              reduce the risk of negative impact of changes to the CCR System.
   334        All interface messages must be archived a configurable number of            IFACE30
              days. Archived messages have to be automatically deleted after
              expiration of retention period.
   335        All archived messages that deal with sensitive data (e.g., username,        IFACE31
              password, SSN, Address information, payment amounts) must be
              encrypted.
   336        All message archiving must be instrumented such that the different          IFACE32
              levels of message information can be archived. At the most minimal
              level, only very basic message information must be archived. At the
              maximum level, both the full contents of the messages, as well as
              relevant environment information, must be archived.
   337        The Contractor must provide a report that displays summary                  IFACE33
              information of the archived interface data for each interface.
   338        Each interface must provide a report that displays detailed                 IFACE34
              information of the archived interface data.
   339        Each interface that uses confidential or sensitive information must         IFACE35
              use a signed/hashed archival method.
   340        Each interface that uses confidential or sensitive data                     IFACE36
              (e.g., username, password, SSN, Address information, payment
              amounts) must use an encrypted channel (e.g., TLS/SSL, VPN,
              secure FTP).
   341        All Interfaces, which perform Login to an external system, must store       IFACE37
              login information in encrypted form.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                  ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 39 of 159


                                                                                                Bidder
Requirement
                                          Requirement                               State Use   Agrees
Number
                                                                                                (Y/N)
   342        Both channels (e.g. web and IVR) must share a common set of           IFACE147
              interfaces. There must not be separate external interfaces for each
              channel.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                            ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 40 of 159



6C.2.3          Detailed Integration Requirements

This section provides detailed descriptions of the integration requirements between the
CCR System and external systems.

6C.2.3.1        Taxable Unemployment Compensation (1099) System Integration

In January the EDD mails out a Form 1099G to claimants who were paid benefits in the prior
calendar year. The Form 1099G itemizes the amount of taxable UI, DI and PFL benefits
received in the calendar year and the amount of federal income tax withheld. The EDD
mails the forms to the address of record at the time the forms are processed, which may no
longer be the claimant‘s current address. The claimant may contact the EDD to get the
1099 information or request a duplicate form or get a listing of taxable benefits paid.
The UIMOD systems must provide claimants the capability, via the IVR and the Web, to
obtain the 1099G information and to request duplicate forms be mailed to the same address
or to a different address.
Both the IVR and the web application must use this interface with the 1099 file to access
and either speak or display the claimant‘s 1099 information. The system must also capture a
request for a duplicate form, capture a different address and send that request to the 1099
system.

6C.2.3.1.1      Request 1099 Information System and Interface Characteristics
           Information Category                                        Description
Application or System Receiving data or
                                           Request for 1099 information (via the IVR or Web)
Requesting Services
Receiving or Requesting Subsystem or       Use Case Claimant: Inquiries Regarding 1099 Forms
Use Case
                                           Use Case Manage Claimant Account via the Web
Application or System Providing the Data   Taxable Unemployment Compensation (1099)
Providing Subsystem or Use Case            None
External System Architecture               VSAM file.
Assumed Integration Interface              FTP 1099 file from mainframe to server
Interface Complexity                       Simple.
Data Transformation                        None
Programming Required on Legacy or
                                           Programming required on Service Provider Application
Service Provider Application
Availability of External System            File available 24 x 7 except for scheduled maintenance




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                 ADDENDUM 3   APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 41 of 159



6C.2.3.1.2      Request 1099 Information Integration Requirements
                                                                                                        Bidder
Requirement
                                             Requirement                                  State Use     Agrees
Number
                                                                                                        (Y/N)
    343         The System must retrieve 1099 information from the 1099 system and        IFACE143
                either display or speak the information to the claimant.



6C.2.3.1.3      Request for Duplicate 1099 System and Interface Characteristics
          Information Category                                           Description
Application or System Receiving or       Request for Duplicate1099 Form via the IVR or Web
Requesting Data/Services
Receiving or Requesting Subsystem        Use Case Claimant: Inquiries Regarding 1099 Forms
or Use Case
                                         Use Case Manage Claimant Account via the Web
Application or System Providing the      Taxable Unemployment Compensation (1099)
Data
Providing Subsystem or Use Case           None
External System Architecture             Mainframe
Assumed Integration Interface            FTP File of requests to the Mainframe
Interface Complexity                     Simple
Data Transformation                      None
Programming Required on Legacy or        Service Provider application
Service Provider Application
Availability of External System          Request file can be sent 24 x 7 except when not available due to
                                         scheduled maintenance



6C.2.3.1.4      Request for Duplicate 1099 Integration Requirements
                                                                                                        Bidder
Requirement
                                             Requirement                                  State Use     Agrees
Number
                                                                                                        (Y/N)
    344         The System must allow the Claimant to request a duplicate 1099 for        IFACE144
                prior calendar years.
    345         If a duplicate 1099 is requested, the System must verify the current      IFACE145
                mailing address for the claimant and capture a new address if
                necessary.
    346         The System must submit a request to the 1099 system to mail a             IFACE146
                duplicate 1099 to the claimant's correct address.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                  ADDENDUM 3             APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                         RFP OSI 7100-181
UIMOD PROJECT                                              SECTION 6C — PAGE 42 of 159



6C.2.3.2       UISS Integration Overview

The UISS legacy system is currently the system of record for scheduling determination of
eligibility appointments for Claimants. In the near term, the CCR System must use the
appointments scheduling functionality of UISS to continue scheduling determination
appointments. In addition to scheduling of appointments, UISS is currently responsible for
initiating the mailing of appointment notifications to Claimants via Office of Documents,
Publications and Distribution (ODPD). Based on current procedural practice, notification
must occur within 10 days. Issues detected in continued claims will be managed by the CCR
System.
This system is targeted for a redesign onto the .NET platform, using SQL/Server, and
should be available in its new form prior to the UIMOD system development initiation.

6C.2.3.2.1     Assumptions

     1. The UISS will remain the sub-system of record for appointments including
        determination issues and disposition.

     2. Currently, UISS appointment information is spooled to the UISS data mart, this
        capability will not be impacted in the short term.

     3. The UISS system provides the user with the option to automatically mail a
        notification — it still needs to be determined if the mail notification should be
        managed by the CCR System or if the CCR System should defer this function to
        UISS. The prevailing thought is that the notification should be the responsibility of
        UISS.

     4. The UISS currently keeps information on appointments and the disposition of
        appointments for 30 days. This information can be accessed by a CSR.


6C.2.3.2.2     Interface Name: UISS Schedule Appointment
The UISS Schedule Appointment interface allows the CCR System to schedule
appointments in the UISS including determination issues.

6C.2.3.2.3     UISS Scheduling Appointment System and Interface Characteristics
        Information Category                                     Description
Application or System Receiving or    CCR System
Requesting Data/Services
Receiving or Requesting Subsystem     Use Case - Cancel and Reschedule Determination Appointment
or Use Case
Application or System Providing the   UISS
Data
Providing Subsystem or Use Case       UISS Appointment


1673D445-8846-415B-9B58-82958E8C824D.DOC                                           ADDENDUM 3      APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 43 of 159



          Information Category                                       Description
External System Architecture            IBM Mainframe; KSDS VSAM file structure
Assumed Integration Interface           ODBC VSAM libraries will be available
Interface Complexity                    Simple
Programming Required on Legacy or       None
Service Provider Application
Availability of External System         The UISS System is available to accept and process UISS
                                        Appointment Requests seven (7) days a week for eighteen hours
                                        per day.



6C.2.3.2.4      UISS Schedule Appointment Integration Requirements
                                                                                                    Bidder
Requirement
                                           Requirement                                 State Use    Agrees
Number
                                                                                                    (Y/N)
    347         The System must provide an interface to the UISS scheduling system     IFACE38
                to schedule appointments.
    348         The System must support a minimum of 4,000 UISS Appointment            IFACE39
                Request transactions a day.
    349         The System must support a minimum of 400 UISS Appointment              IFACE40
                Request transactions at peak hour.
    350         The System must communicate UISS Appointment Requests via              IFACE41
                Message Queue.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                              ADDENDUM 3             APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 44 of 159



6C.2.3.2.5     Interface Name: UISS Cancel Appointment
The UISS Cancel Appointment interface allows the CCR System to cancel previously
scheduled appointments in the UISS System. The interface should include capability to
record reasons for cancellation.


6C.2.3.2.6     UISS Cancel Appointment System and Interface Characteristics
         Information Category                                          Description
Application or System Receiving or        CCR System
Requesting Data/Services
Receiving or Requesting Subsystem         Use Case - Manage Claimant Account
or Use Case
Application or System Providing the       UISS
Data
Providing Subsystem or Use Case           UISS Appointment
External System Architecture              IBM Mainframe; DB2
Assumed Integration Interface             ODBC DB2 libraries will be available
Interface Complexity                      Moderate
Programming Required on Legacy or         A work queue management process will be required as well as a
Service Provider Application              process to take the cancellation request and to apply the request to
                                          the database.
Availability of External System           The UISS System is available to accept and process UISS Cancel
                                          Appointment requests seven (7) days a week, eighteen hours
                                          per day.



6C.2.3.2.7     UISS Cancel Appointment Integration Requirements
                                                                                                         Bidder
Requirement
                   Context                           Requirement                          State Use      Agrees
Number
                                                                                                         (Y/N)
   351        Integration         The System must provide an interface to the UISS         IFACE42
              Needs               scheduling system to cancel appointments.
   352        Daily Volume        The System must support a minimum of 4,000 UISS          IFACE43
              /Load               Cancel Appointment transactions a day.
   353        Peak Hour           The System must support a minimum of 400 UISS            IFACE44
              Messaging           Cancel Appointment transactions at peak hour.
              Volume
   354        Communication       The System must communicate UISS Cancel                  IFACE45
              Style               Appointment requests via message queue.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                  ADDENDUM 3              APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 45 of 159



6C.2.3.2.8     Interface Name: UISS Lookup Appointment

The UISS Lookup Appointment Interface provides the CCR System with the capability to
look up the time of an appointment based on the Claimant unique UI identifier. This interface
should also support the capability of retrieving appointment history and appointment
disposition information (for the previous 30 days).

6C.2.3.2.9     UISS Lookup Scheduling System and Interface Characteristics
         Information Category                                         Description
Application or System Receiving or         CCR System
Requesting Data/Services
Receiving or Requesting Subsystem or       Use Case - Manage Claimant Account
Use Case
Application or System Providing the        UISS
Data
Providing Subsystem or Use Case            UISS Appointment
External System Architecture               IBM Mainframe; DB2 Database
Assumed Integration Interface              ODBC DB2 libraries will be available
Interface Complexity                       Simple
Programming Required on Legacy or          None
Service Provider Application
Availability of External System            The UISS System is available to accept and process UISS Lookup
                                           Appointment requests seven (7) days a week, eighteen hours
                                           per day.



6C.2.3.2.10 UISS Lookup Appointment Integration Requirements
                                                                                                  Bidder
Requirement
                   Context                          Requirement                       State Use   Agrees
Number
                                                                                                  (Y/N)
   355        Integration         The System must provide an interface to the UISS    IFACE46
              Needs               system to look up the time and date of previously
                                  scheduled appointments based on the Claimant
                                  unique UI identifier.
   356        Daily Volume        The System must support a minimum of 4,000          IFACE47
              /Load               UISS Lookup Appointment transactions a day.
   357        Peak Hour           The System must support a minimum of 400 UISS       IFACE48
              Messaging           Lookup Appointment transactions at peak hour.
              Volume
   358        Communication       The System must communicate UISS Lookup             IFACE49
              Style               Appointment requests via on-line message
                                  request.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                              ADDENDUM 3            APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 46 of 159



6C.2.3.3        United States Postal Service (USPS) Systems Integration

One of the requirements of the CCR System is to maintain correct addresses for Claimants
and other stakeholders. To improve the likelihood of having correct addresses, it is
envisioned that the CCR System will leverage the addressing verification services offered by
the United States Postal Service. The USPS is assumed to provide a simple XML/Web
Services interface exposed over the Web to allow EDD to validate addresses in real time.

6C.2.3.3.1      Interface Name: USPS Validate Address

This interface is a Web service to allow the CCR System to validate an address against the
United States Postal Service (USPS) address validation service.

6C.2.3.3.2      USPS Validate Address – System and Interface Characteristics
           Information Category                                        Description
Application or System Receiving data or    CCR System
Requesting Services
Receiving or Requesting Subsystem or       Use Case - Update Demographics
Use Case
Application or System Providing the Data   USPS
Providing Subsystem or Use Case            None
External System Architecture               Web Services over Public Web
Assumed Integration Interface              The USPS is assumed to provide a simple XML/Web Services
                                           interface exposed over the Web to allow EDD to validate addresses
                                           in real time.
Interface Complexity                       Simple
Data Transformation                        Assumed none — All data will be formatted using XML and based
                                           on U.S. Postal Services Addressing formats.
Programming Required on Legacy or          None
Service Provider Application
Availability of External System            The USPS System is available to accept and receive USPS Validate
                                           Address requests seven (7) days a week, 24 hours per day.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                ADDENDUM 3             APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 47 of 159



6C.2.3.3.3    USPS Validate Address Integration Requirements
                                                                                                  Bidder
Requirement
              Context                              Requirement                        State Use   Agrees
Number
                                                                                                  (Y/N)
   359        Overview of      The System must use USPS data to validate              IFACE50
              Integration      claimant addresses. The UIMOD project would
              Needs            prefer that the System use a USPS-provided web
                               service, if available. If USPS Web Services will not
                               be available, a web services-based solution that
                               uses regularly-refreshed USPS data will need to be
                               procured or developed.
   360        Daily            The System must support a minimum of 10,000            IFACE51
              Volume/Load      USPS Validate Address transactions a day.
   361        Peak Hour        The System must support a minimum of 1000 USPS         IFACE52
              Messaging        Validate Address transactions at peak hour.
              Volume
   362        Communication    The System must communicate USPS Validate              IFACE53
              Style            Address requests via message queue.
   363        Error Handling   If an address can not be validated because the         IFACE54
                               receiving System or network is down, the System
                               must allow the Update Demographics process to
                               continue un-interrupted. However, it is assumed that
                               USPS Validate Address requests must be queued
                               up for later processing which must happen
                               automatically.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                              ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                          RFP OSI 7100-181
UIMOD PROJECT                                               SECTION 6C — PAGE 48 of 159



6C.2.3.4         UIS Systems Integration

The UIS legacy system is currently the system of record for Initial Claim and maintaining
Claimant payment history. This system also acts as system of record for payment
information for the Benefit Accounting System which also supports Disability Insurance.


6C.2.3.4.1     Assumptions

   1. The current UIS benefits database does not support the continued claims
      requirements of the CCR System. The goal of UI is to establish a new Continued
      Claims Certification system which will be the system of record for UI claimant
      eligibility and payment information.

   2. The existing UIS benefits database will remain in place since it supports other
      downstream applications. Updates will be driven through the new CCR System
      database.

   3. Legacy applications for updating payment and claim related changes will not be
      modified to update the CCR System Demographics System of records at point of
      capture.

While the planned system of record for UI Claim and Payment information will be the CCR
System, the UIS System will continue to be in use for Initial Claims, Claim Corrections (a.k.a.
Recomps), Benefit Accounting and Overpayment activity. Thus, it is critical that the claim
and payment information is kept synchronized between the new CCR System and the
Legacy UIS.

6C.2.3.4.2     Interface Name: CCR System Update Claim Change
This interface/integration point ensures that the claim and payments related data altered in
UIS during Claim Correction processing is propagated and synchronized in the CCR
System.

6C.2.3.4.3     CCR System Update Claim Changes – System and Interface Characteristics
           Information Category                                        Description
Application or System Receiving or         A claim change and/or a recomputation have effected a change
Requesting Data/Services                   to a claim that affects reporting, payment processing, or the need
                                           for adjustment payments out of CCR.
Receiving or Requesting Subsystem or Use   CCR System
Case
Application or System Providing the Data   UIS Claim Corrections
Providing Subsystem or Use Case            Process Work Queues and Process Decisions
External System Architecture               Mainframe SCDB IDMS Database
Assumed Integration Interface              To be determined /proposed by contractor.


1673D445-8846-415B-9B58-82958E8C824D.DOC                                               ADDENDUM 3               APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 49 of 159



            Information Category                                         Description
Interface Complexity                        Complex — Custom solution needs to be developed to recognize
                                            a variety of services being required. Services include:
                                                   Claim cancellation
                                                   Effective date change (forward and back)
                                                   Transfer of claim from one SSN to another
                                                   Making claim monetarily invalid insufficient earnings
                                                   Making claim monetarily invalid no earnings
                                                   Reducing weekly benefit amount
                                                   Increasing weekly benefit amount
                                                   Reducing maximum benefit amount
                                                   Increasing maximum benefit amount
                                                   Changing the balance available to be paid
                                                   Furthermore, the CCR System needs a mechanism to
                                                    ensure that changes to CCR System claim data does not
                                                    trigger an infinite loop.
Data Transformation                         Data transformation and cleansing is required to reflect
                                            differences in treatment of data (e.g. SSN is a key in legacy but a
                                            claimant characteristic in CCR)
                                            There may be an opportunity for third party software for address
                                            cleansing.
Programming Required on Legacy or           To be determined /proposed by contractor.
Service Provider Application
Availability of External System             The UIS System is available to send CCR System claim and
                                            payment change requests five (5) days a week, twelve (12) hours
                                            per day.



6C.2.3.4.4      CCR System Update Claim Changes Interface Integration Requirements
                                                                                                       Bidder
Requirement
                                          Requirement                                    State Use     Agrees
Number
                                                                                                       (Y/N)
    364         The UIS must integrate with the CCR System to ensure claim and           IFACE55
                payment maintenance information is synchronized when a change
                occurs in the CCR System database.
    365         The System must support a minimum of 35,000 new claim change             IFACE56
                updates daily.
    366         The System must support a minimum of 5,000 CCR Update Claim              IFACE57
                change requests transactions (from UIS) hourly.
    367         The System must communicate CCR System Update Claim Change               IFACE58
                requests via message queue or batch.



1673D445-8846-415B-9B58-82958E8C824D.DOC                                                 ADDENDUM 3               APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                         RFP OSI 7100-181
UIMOD PROJECT                                              SECTION 6C — PAGE 50 of 159




6C.2.3.4.5 Interface Name: CCR System Update Demographics System Integration
        (CCR to UIS)

The CCR System is the system of record and all changes to UI Claim addresses and
demographics. To support existing functionality of the UIS, the CCR System is required to
provide the UIS with up-to-date address and demographics information. Note, the residence
address is put in the notes format if different than the mailing address. Certain
demographics updates require transaction records to be created. The interface/service is
used by the CCR System to ensure that Claimant changes to demographics information in
the CCR System‘s database are also provided to UIS to allow synchronization of data.

6C.2.3.4.6      UIS Update Demographics – System and Interface Characteristics
          Information Category                                     Description
Application or System Receiving or     UIS
Requesting Data/Services
Receiving or Requesting Subsystem or   Claim Filing
Use Case
                                       Client Locator
Application or System Providing the    CCR System
Data
Providing Subsystem or Use Case        Use Case - Update Demographics
External System Architecture           IBM Mainframe; IDMS file structure
Assumed Integration Interface          To be determined /proposed by contractor.
Interface Complexity                   Complex — Custom solution needs to detect changes to the CCR
                                       System that need to be applied to the SCDB and invoke an interface
                                       request.
Data Transformation                    Address data may need truncating and other data may require
                                       transformation.
Programming Required on Legacy or      To be determined /proposed by contractor.
Service Provider Application
Availability of External System        The UIS System is available to accept and process UIS Update
                                       Demographics requests five (5) days a week, twelve (12) hours
                                       per day.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                             ADDENDUM 3             APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                     RFP OSI 7100-181
UIMOD PROJECT                                          SECTION 6C — PAGE 51 of 159



6C.2.3.4.7    UIS Update Demographics Interface Integration Requirements
                                                                                          Bidder
Requirement
              Context                          Requirement                    State Use   Agrees
Number
                                                                                          (Y/N)
   368        Integration     The System must integrate with the UIS system   IFACE59
              Needs           to ensure demographics information is
                              synchronized when a change occurs in the CCR
                              System database.
   369        Daily Volume    The System must support a minimum of 10,000     IFACE60
              /Load           UIS Update Demographics requests transactions
                              a day.
   370        Peak Hour       The System must support a minimum of 1000       IFACE61
              Messaging       UIS Update Demographics requests transactions
              Volume          at peak hour.
   371        Communication   The System must communicate UIS Update          IFACE62
              Style           Demographics requests via message queue. If
                              address update fails at SCDB side because of
                              format issues, there must be manual
                              intervention - less than two percent (2%) of
                              addresses may require manual intervention.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                      ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 52 of 159



6C.2.3.5         UIS Claims Integration

The CCR System needs to update/synchronize records currently stored/updated in the
SCDB database by the UIS continued claims process. These records are required by other
processes supported by UIS. Example of information required by UIS and downstream
processes include:
     1. Claims information (status, balance, WBA, most recent weeks certified, etc.)
     2. Eligibility requirements for the Claimant (flags, seek work plan, waiting period, etc.).
     3. Reductions and barriers to payments.

6C.2.3.5.1     Assumptions
     1. No update to Continued Claims data will occur through the Legacy UIS Claims
        System.
     2. WBCF and Initial claim will be reengineered to update initial claims data in the new
        systems.
     3. The existing UIS demographics database will still be required to feed a large
        number of down stream systems and will be updated by the CCR System
        continued claims database.
     4. The interface will be responsible for translating Claims information, eligibility
        requirements and to create activity logs for downstream processes. Some of
        activity logs include:
                   a) Claim action,
                   b) Weekly action,
                   c) Determinations, and
                   d) Flags.

This interface allows Claims information in UIS to be synchronized and updated by the CCR
System.

6C.2.3.5.2     UIS Claims Update – System Interface Characteristics
         Information Category                                          Description
Application or System Receiving data or   UIS
Requesting Services
Receiving or Requesting Subsystem or      Claim Record
Use Case
                                          Claim History
Application or System Providing the       CCR System
Data
Providing Subsystem or Use Case           Use Case - Certify for Benefits
                                          Use Case - Additional Claims
External System Architecture              IBM Mainframe; IDMS file structure
Assumed Integration Interface             To be determined /proposed by contractor.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                              ADDENDUM 3   APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 53 of 159



          Information Category                                           Description
Interface Complexity                         Complex — Multiple IDMS/SQL table procedures will be required
                                             based on the type of continued claim activity that needs to be
                                             passed. Transaction records will also have to be stored. Coding
                                             using CA ODBC Bridge will be required.
Updates of activity logs will be required.   None
Data Transformation                          Data must be transformed from XML to legacy format.
Programming Required on Legacy or            To be determined /proposed by contractor.
Service Provider Application
Availability of External System              The UIS System is available to accept and process UIS Claims
                                             Update requests five (5) days a week, twelve (12) hours per day.



6C.2.3.5.3       UIS Claims Update Integration Requirements
                                                                                                         Bidder
Requirement
                 Context                               Requirement                         State Use     Agrees
Number
                                                                                                         (Y/N)
    372         Integration         The System must provide an interface to the UIS         IFACE63
                Needs               system for claims update.
    373         Daily Volume        The System must support a minimum of 543,000            IFACE64
                /Load               UIS Claims Update transactions a day.
    374         Peak Hour           The System must support a minimum of 52,000             IFACE65
                Messaging           UIS Claims Update transactions at peak hour.
                Volume
    375         Communication       The System must communicate UIS Claims Update           IFACE66
                Style               requests via a mechanism that guarantees delivery
                                    of claimant data to SCDB (e.g. message queuing).




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                   ADDENDUM 3             APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
UIMOD PROJECT                                                     SECTION 6C — PAGE 54 of 159



6C.2.3.6          Disability Insurance System (DIS) Systems Integration

The CCR System must ensure there is no overlap of benefits with DIS. Before calculating
the check to the Claimant, the CCR System must check if there are any active Disability
Insurance (DI) claims with a potential overlap for benefits. The data for active DI claims is
stored in SCDB-DIS. Today, DIS can access UIS and make changes to Claimant
demographics.
The requirements for demographics and address information for DIS is discussed in the UIS
integration section.
This interface provides a service to the CCR System to check for disability/paid family leave
claim overlap(s) with UI benefits.

6C.2.3.6.1      Check for Disability Overlap Interface: System and Interface Characteristics
          Information Category                                            Description
Application or System Receiving or           CCR System
Requesting Data/Services
Receiving or Requesting Subsystem or         Use Case - Additional Claims
Use Case
                                             Use Case - Calculate Payment
Application or System Providing the          DIS
Data
Providing Subsystem or Use Case              DI Transaction Records
External System Architecture                 IBM Mainframe; IDMS file structure
Assumed Integration Interface                To be determined /proposed by contractor.
Interface Complexity                         Moderate
Programming Required on Legacy or            To be determined /proposed by contractor.
Service Provider Application
Availability of External System              The DI System is available to accept and process Check for Disability
                                             Overlap requests five (5) days a week, twelve (12) hours per day.



6C.2.3.6.2      Check for Disability Overlap Integration Requirements
                                                                                                          Bidder
Requirement
                Context                                  Requirement                        State Use     Agrees
Number
                                                                                                          (Y/N)
    376         Integration           The System must provide an interface to the DIS        IFACE67
                Needs                 to allow the CCR System to evaluate potential
                                      UI/DI program payment overlap.
    377         Daily Volume          The System must support a minimum of 900               IFACE68
                /Load                 Check for Disability Overlap transactions a day.
    378         Peak Hour             The System must support a minimum of 75 Check          IFACE69
                Messaging             for Disability Overlap transactions at peak hour.
                Volume

1673D445-8846-415B-9B58-82958E8C824D.DOC                                                    ADDENDUM 3               APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                       RFP OSI 7100-181
UIMOD PROJECT                                            SECTION 6C — PAGE 55 of 159


                                                                                           Bidder
Requirement
              Context                           Requirement                    State Use   Agrees
Number
                                                                                           (Y/N)
   379        Communication   The System must communicate Check for            IFACE70
              Style           Disability Overlap requests via message queue.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                       ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                         RFP OSI 7100-181
UIMOD PROJECT                                              SECTION 6C — PAGE 56 of 159



6C.2.3.7         BAS Systems Integration
The Benefits Accounting System (BAS) is used to process accounting of Unemployment
Insurance and Disability Insurance benefit payments and overpayments. This includes
tracking disbursement of funds to other entities, reconciliation of bank accounts, posting
payment transactions to Claimant overpayments, etc. The BAS runs on the IBM mainframe
and uses the SCDB as its primary store.

6C.2.3.7.1     Assumptions
     1. Continued Claims calculation of benefits amount is the responsibility of the CCR
        System.
     2. Payment and what actually goes on to the check is the responsibility of the CCR
        System.
     3. Continued Claims should have access to payment information — not necessarily in
        real time.
     4. Continued Claims can access warrant information.
     5. The BAS can change the characteristics of any week claimed.
     6. The BAS Overpayment System (which is a separate sub-system responsible for
        overpayment and collections) will remain and continue to be used. However, the
        CCR System will have the functionality to calculate overpayment offset and notify
        the BAS Overpayment System. That is, overpayment offset functionality will be
        moved from BAS to Continued Claims (See Appendix C - Calculate Payment Use
        Case).


6C.2.3.7.2     Interface Name: Check for Benefits Payments Reallocation

This interface allows the CCR System to access BAS accounting activities reflected in the
adjustment records for each week, identify changes and extract this information and upload
into CCR System databases.

6C.2.3.7.3     Check for Benefits Payment Reallocation – System and Interface Characteristics
         Information Category                                       Description
Application or System Receiving or     CCR System
Requesting Data/Services
Receiving or Requesting Subsystem or   None
Use Case
Application or System Providing the    BAS
Data
Providing Subsystem or Use Case        BAS Adjustment Records
External System Architecture           IBM Mainframe; — flat file structure
Assumed Integration Interface          To be determined /proposed by contractor.


1673D445-8846-415B-9B58-82958E8C824D.DOC                                           ADDENDUM 3   APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 57 of 159



          Information Category                                         Description
Interface Complexity                     Complex — This is a complicated interaction with high risk for data
                                         integrity issues. Continued Claims staff will notify Insurance
                                         Accounting Division (IAD) of any changes related to "transfer week"
                                         or "change of week ending.‖ The notification is either via e-mail or
                                         some workflow. The IAD staff will enter changes into BAS including:
                                               Weekly action record
                                               Weekly reduction record
                                               Accounting transaction record.
                                         The BAS will reallocate payment(s) which must be updated in the
                                         CCR System database.
Programming Required on Legacy or        To be determined /proposed by contractor.
Service Provider Application
Availability of External System          The BAS System is available to accept and process Check for
                                         Benefits Payment Reallocation requests five (5) days a week, twelve
                                         (12) hours per day.



6C.2.3.7.4      Check for Benefits Payment Reallocation Integration Requirements
                                                                                                      Bidder
Requirement
                Context                             Requirement                         State Use     Agrees
Number
                                                                                                      (Y/N)
    380         Integration       The System must recognize an SCDB benefit             IFACE71
                Needs             payment accounting adjustment and synchronize
                                  the CCR System databases.
    381         Daily Volume      The System must support a minimum of 500              IFACE72
                /Load             Check for Benefits Payment Reallocation
                                  transactions a day.
    382         Peak Hour         The System must support a minimum of 50 Check         IFACE73
                Messaging         for Benefits Payment Reallocation transactions at
                Volume            peak hour.
    383         Communication     The System must communicate Check for                 IFACE74
                Style             Benefits Payment Reallocation requests via
                                  message queue.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                ADDENDUM 3              APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 58 of 159



6C.2.3.7.5     Interface Name: Check for Overpayment

In the case when a Claimant has been overpaid, this information is flagged in the BAS OP
system. In addition, any payments, adjustments or changes to overpayment status are
recorded in the BAS OP system. In order for the CCR System to calculate payments for the
next week ending period, the CCR System needs access to this information. This interface
allows the CCR System to access the BAS overpayment sub-system to ensure that the
CCR System has accurate information of overpayment.

6C.2.3.7.6         Check for Overpayment – System and Interface Characteristics
         Information Category                                            Description
Application or System Receiving or          CCR System
Requesting Data/Services
Receiving or Requesting Subsystem or        Use Case - Calculate Payment
Use Case
Application or System Providing the         BAS
Data
Providing Subsystem or Use Case             BAS OP
External System Architecture                IBM Mainframe; IDMS file structure
Assumed Integration Interface               To be determined /proposed by contractor.
Interface Complexity                        Complex
Programming Required on Legacy or           To be determined /proposed by contractor.
Service Provider Application
Availability of External System             The BAS System is available to accept and process Check for
                                            Overpayment requests five (5) days a week, twelve (12) hours
                                            per day.



6C.2.3.7.7         Check for Overpayment Integration Requirements
                                                                                                       Bidder
Requirement
               Context                                 Requirement                       State Use     Agrees
Number
                                                                                                       (Y/N)
   384         Integration           The System must interface with the BAS               IFACE75
               Needs                 Overpayment records to obtain overpayment
                                     information for calculating overpayment offsets.
   385         Daily Volume          The System must support a minimum of 2500            IFACE76
               /Load                 Check for Overpayment transactions a day.
   386         Peak Hour             The System must support a minimum of 250             IFACE77
               Messaging             Check for Overpayment transactions at peak
               Volume                hour.
   387         Communication         The System must communicate Check for                IFACE78
               Style                 Overpayment requests via message queue.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                 ADDENDUM 3             APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 59 of 159




6C.2.3.7.8          Interface Name: Posting Overpayment Offset

This interface allows the CCR System to report to the BAS overpayment sub-system that
the CCR System has taken an overpayment offset and allow the OP system to allocate the
offset to the appropriate overpayments(s).

6C.2.3.7.9          Posting Overpayment Offset – System and Interface Characteristics
          Information Category                                           Description
Application or System Receiving or         BAS
Requesting Data/Services
Receiving or Requesting Subsystem or       BAS OP
Use Case
Application or System Providing the        CCR System
Data
Providing Subsystem or Use Case            Use Case - Initiate Payment Distribution
External System Architecture               IBM Mainframe; IDMS file structure
Assumed Integration Interface              To be determined /proposed by contractor.
Interface Complexity                       Complex
Programming Required on Legacy or          To be determined /proposed by contractor.
Service Provider Application
Availability of External System            The BAS System is available to accept and process Posting
                                           Overpayment Offset requests five (5) days a week, twelve (12) hours
                                           per day.



6C.2.3.7.10         Posting Overpayment Offset Integration Requirements
                                                                                                     Bidder
Requirement
                Context                              Requirement                       State Use     Agrees
Number
                                                                                                     (Y/N)
    388        Integration        The System must utilize benefit accounting           IFACE79
               Needs              business rules to calculate and allocate the
                                  overpayment offset taken for a certified week.
    389        Daily Volume       The System must support a minimum of 2000            IFACE80
               /Load              Posting Overpayment Offset transactions a day.
    390        Peak Hour          The System must support a minimum of 200             IFACE81
               Messaging          Posting Overpayment Offset transactions at peak
               Volume             hour.
    391        Communication      The System must communicate Posting                  IFACE82
               Style              Overpayment Offset requests via message queue.
6C.2.3.7.11         Interface Name: Capture Established Overpayment Information
This interface allows the CCR System to record the amount a specific week has been
overpaid when the overpayment is established.

1673D445-8846-415B-9B58-82958E8C824D.DOC                                                 ADDENDUM 3              APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 60 of 159




6C.2.3.7.12        Capture Established Overpayment Information – System and Interface
                   Characteristics
         Information Category                                          Description
Application or System Receiving or         CCR System
Requesting Data/Services
Receiving or Requesting Subsystem or       Use Case - Customer Service
Use Case
                                           Use Case - Process Decisions
Application or System Providing the        BAS
Data
Providing Subsystem or Use Case            Overpayment Establishment
External System Architecture               IBM Mainframe; IDMS file structure
Assumed Integration Interface              To be determined/proposed by bidder.
Interface Complexity                       Moderate
Programming Required on Legacy or          To be determined/proposed by bidder.
Service Provider Application
Availability of External System            The BAS System is available to accept and process Capture
                                           Established Overpayment Information requests five (5) days a week,
                                           twelve (12) hours per day.



6C.2.3.7.13        Capture Established Overpayment Information Integration Requirements
                                                                                                      Bidder
Requirement
               Context                                Requirement                       State Use     Agrees
Number
                                                                                                      (Y/N)
   392        Integration         The System must recognize when an overpayment         IFACE83
              Needs               is established and record the amount a specific
                                  week has been overpaid.
   393        Daily Volume        The System must support establishing a minimum        IFACE84
              /Load               of 3000 Overpayment Information transactions per
                                  day.
   394        Peak Hour           The System must support establishing a minimum        IFACE85
              Messaging           of 500 Overpayment Information transactions at
              Volume              peak hour.
   395        Communication       The System must communicate Capture                   IFACE86
              Style               Established Overpayment Information requests via
                                  message queue.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                ADDENDUM 3              APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 61 of 159



6C.2.3.8           Office of Appeal (OAP) Systems Integration

The CCR System must notify the Office of Appeal of any Claimant change of address when
the Claimant has an active appeal. Today, this is done manually via mail or e-mail. The
appeal workload is distributed across Offices of Appeal Statewide by Claimant‘s ZIP code.

6C.2.3.8.1           Interface Name: Notify OAP of Address Change

This interface allows the CCR System to notify Office of Appeal of a Claimant address
change using SMTP e-mail functionality.

6C.2.3.8.2           Notify OAP of Address Change – System and Interface Characteristics
          Information Category                                       Description
Application or System Receiving or     OAP
Requesting Data/Services
Receiving or Requesting Subsystem      N/A
or Use Case
Application or System Providing the    CCR System
Data
Providing Subsystem or Use Case        Use Case - Update Demographics
External System Architecture           SMTP e-mail
Assumed Integration Interface          SMTP e-mail
Interface Complexity                   Simple
Data Transformation                    None
Programming Required on Legacy         None
or Service Provider Application
Availability of External System        The OAP System is available to accept and process Notify OAP of
                                       Address Change requests seven (7) days a week, 24 hours per day.



6C.2.3.8.3           Notify OAP of Address Change Integration Requirements
                                                                                                    Bidder
Requirement
                 Context                             Requirement                       State Use    Agrees
Number
                                                                                                    (Y/N)
    396         Integration       The System must provide an interface to EDD          IFACE91
                Needs             SMTP e-mail system for delivery of address change
                                  notification to Office of Appeal.
    397         Daily Volume      The System must support a minimum of 60 Notify       IFACE92
                /Load             OAP of Address Change transactions a day.
    398         Peak Hour         The System must support a minimum of 20 Notify       IFACE93
                Messaging         OAP of Address Change transactions at peak hour.
                Volume




1673D445-8846-415B-9B58-82958E8C824D.DOC                                               ADDENDUM 3            APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                       RFP OSI 7100-181
UIMOD PROJECT                                            SECTION 6C — PAGE 62 of 159


                                                                                          Bidder
Requirement
              Context                           Requirement                   State Use   Agrees
Number
                                                                                          (Y/N)
   399        Communication   The System must communicate Notify OAP of       IFACE94
              Style           Address Change requests via message queue.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                      ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 63 of 159



6C.2.3.9                Wage File System (WGS) Integration
The CCR System must integrate with WGS to extract employer Tax ID for employers who
have reported wages for a Claimant. This information is subsequently used to access
employer address information in the Tax Accounting System (TAS).

6C.2.3.9.1          Interface Name: Get Employer Tax ID

This interface is used to obtain employer Tax ID from the WGS system.

6C.2.3.9.2          Get Employer Tax ID – System and Interface Characteristics
          Information Category                                          Description
Application or System Receiving or       CCR System
Requesting Data/Services
Receiving or Requesting Subsystem or     Use Case - Certify for Benefits
Use Case
                                         Use Case - Additional Claims
Application or System Providing the      WGS
Data
Providing Subsystem or Use Case          Wages by SSN
External System Architecture             Mainframe DB2 database
Assumed Integration Interface            ODBC drivers
Interface Complexity                     Simple
Data Transformation                      None
Programming Required on Legacy or        None
Service Provider Application
Availability of External System          The WGS System is available to accept and process Get Employer
                                         Tax ID requests seven (7) days a week, 24 hours per day.



6C.2.3.9.3          Get Employer Tax ID Integration Requirements
                                                                                                   Bidder
Requirement
                Context                              Requirement                      State Use    Agrees
Number
                                                                                                   (Y/N)
    400        Integration        The System must integrate with WGS to extract        IFACE95
               Needs              employer Tax ID by matching to an employee SSN.
    401        Daily Volume       The System must support a minimum of 8,200 Get       IFACE96
               /Load              Employer Tax ID transactions a day.
    402        Peak Hour          The System must support a minimum of 800 Get         IFACE97
               Messaging          Employer Tax ID transactions at peak hour.
               Volume
    403        Communication      The System must communicate Get Employer Tax         IFACE98
               Style              ID requests via message queue.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                              ADDENDUM 3            APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 64 of 159



6C.2.3.10         Tax Accounting System (TAS) Integration

The CCR System must integrate with the Tax Accounting System to extract employer name
and address using Tax ID in real time.
This interface provides the CCR System with employer name and address based on Tax ID.

6C.2.3.10.1         Get Employer Name and Address by Tax ID – System and Interface
                    Characteristics
          Information Category                                           Description
Application or System Receiving or        CCR System
Requesting Data/Services
Receiving or Requesting Subsystem or      Use Case - Certify for Benefits
Use Case
                                          Use Case - Additional Claims
Application or System Providing the       TAS
Data
Providing Subsystem or Use Case           Employer information database
External System Architecture              Mainframe IDMS
Assumed Integration Interface             To be determined /proposed by contractor.
Interface Complexity                      Simple
Data Transformation                       None
Programming Required on Legacy or         To be determined /proposed by contractor.
Service Provider Application
Availability of External System           The TAS System is available to accept and process Get Employer
                                          Name and Address by Tax ID requests five (5) days a week, twelve
                                          (12) hours per day.



6C.2.3.10.2         Get Employer Name and Address by Tax ID Integration Requirements
                                                                                                     Bidder
Requirement
                Context                              Requirement                       State Use     Agrees
Number
                                                                                                     (Y/N)
    404        Integration        The System must provide an interface to the TAS      IFACE99
               Needs              system to extract Employer addresses.
    405        Daily Volume       The System must support a minimum of 8,200 Get       IFACE100
               /Load              Employer Name and Address by Tax ID
                                  transactions a day.
    406        Peak Hour          The System must support a minimum of 800 Get         IFACE101
               Messaging          Employer Name and Address by Tax ID
               Volume             transactions at peak hour.
    407        Communication      The System must communicate Get Employer             IFACE102
               Style              Name and Address by Tax ID requests via message
                                  queue.



1673D445-8846-415B-9B58-82958E8C824D.DOC                                               ADDENDUM 3             APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 65 of 159



6C.2.3.11          ODPD Integration Overview

Today, as part of the check printing process, the Office of Documents, Publications and
Distribution (ODPD), is responsible for assigning check warrant numbers. The ODPD
produces a batch file with check warrant numbers that is used to update the SCDB.


6C.2.3.11.1        ODPD Systems Integration

Office of Documents, Publications and Distribution (ODPD) is used today by EDD to send
printed material and notifications to Claimants, Employers, etc. Examples of communication
include:
     1.   Issuing warrants,
     2.   Sending notification of password reset change via USPS,
     3.   Issuing forms via USPS to Claimants, and
     4.   Issuing forms via USPS to Employers.
The CCR System must integrate with the ODPD system for printing and sending notices
and forms to external stakeholders. While there may be opportunities to develop Web
services for each type of form and notice, for the purpose of describing the integration
requirements, we assume that there will be a single integration interface for all notifications.


6C.2.3.11.2        Interface Name: Capture Check Warrant Information

This interface/integration provides the CCR System with the capability to capture and store
check warrant numbers. It is assumed that the CCR System will leverage the daily ODPD
batch file.


6C.2.3.11.3        Capture Check Warrant Information – System and Interface
                   Characteristics
          Information Category                                     Description
Application or System Receiving or     CCR System
Requesting Data/Services
Receiving or Requesting Subsystem or   None
Use Case
Application or System Providing the    ODPD
Data
Providing Subsystem or Use Case        Warrant Update
External System Architecture           IBM Mainframe, flat file
Assumed Integration Interface          Secure FTP batch file access via FTP on HTTP download.
Data Transformation                    None




1673D445-8846-415B-9B58-82958E8C824D.DOC                                           ADDENDUM 3      APRIL 8
 OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
 UIMOD PROJECT                                                    SECTION 6C — PAGE 66 of 159



           Information Category                                            Description
 Programming Required on Legacy or          None
 Service Provider Application
 Availability of External System            The ODPD System is available to accept and process ODPD
                                            Notification Interface requests six (6) days a week, 24 hours per day.


6C.2.3.11.4          Capture Check Warrant Information - Integration Requirements
                                                                                                           Bidder
 Requirement
                 Context                               Requirement                           State Use     Agrees
 Number
                                                                                                           (Y/N)
     408        Integration        The System must be integrated with ODPD for              IFACE87
                Needs              capturing of Check warrant information.
     409        Daily Volume       The System must support a minimum of 260,000             IFACE88
                /Load              Check Warrant updates per day.
     410                           The System must update Check Warrant                     IFACE89
                                   information during daily batches.
     411        Communication      The System must communicate through secure               IFACE90
                Style              (encrypted) FTP for any interface that requires files
                                   be sent via FTP file transfer.




 1673D445-8846-415B-9B58-82958E8C824D.DOC                                                   ADDENDUM 3               APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                          RFP OSI 7100-181
UIMOD PROJECT                                               SECTION 6C — PAGE 67 of 159



6C.2.3.11.5         Interface Name: ODPD Notification Interface
This interface will send information to ODPD for distribution via USPS.


6C.2.3.11.6         ODPD Notification Interface – System and Interface Characteristics
          Information Category                                       Description
Application or System Receiving or     CCR System
Requesting Data/Services
Receiving or Requesting Subsystem or   Use Case - Update Demographics via the Web
Use Case
                                       Use Case - Change Password
                                       Use Case - Certify for Benefits
                                       Use Case - Request Lost or Stolen Check Forms
                                       Use Case - Additional Claim
                                       Use Case - Initiate Payment Distribution
Application or System Providing the    ODPD
Data
Providing Subsystem or Use Case        None
External System Architecture           Print services supporting XML and PostScript input files via FTP
                                       server.
Assumed Integration Interface          FTP file transfer
Interface Complexity                   Simple
Data Transformation                    None
Programming Required on Legacy or      New application using Extreme software (to be programmed by
Service Provider Application           ODPD).
Availability of External System        The ODPD System is available to accept and process ODPD
                                       Notification Interface requests six days a week, 24 hours per day.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                               ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                         RFP OSI 7100-181
UIMOD PROJECT                                              SECTION 6C — PAGE 68 of 159



6C.2.3.11.7        ODPD Notification Interface – Interface Requirements
                                                                                               Bidder
Requirement
              Context                            Requirement                       State Use   Agrees
Number
                                                                                               (Y/N)
   412        Integration     The System must integrate and use ODPD for all       IFACE103
              Needs           notification via USPS.
   413        Daily Volume    The System must support a minimum of (See            IFACE104
              /Load           Bidders' Library, Forms folder):
                              a) 8,214 Employer Notifications (DE1101CZ),
                              b) 1,940 DE1080CSI Notifications,
                              c) 8,214 DE1101CLMT Notifications,
                              d) 134,875 DE4581s (no warrant attached),
                              e) 56,822 Message stubs (no warrant attached),
                              f) 260,000 Warrants (majority have 4581s attached,
                              all have message stubs),
                              g) 100 DE8784s, and/or
                              h) 400 DE731.
   414        Peak Hour       The System must support a minimum peak hour          IFACE105
              Messaging       traffic as follows (See Bidders' Library, Forms
              Volume          folder):
                              a) 784 Employer Notifications (DE1101CZ),
                              b) 185 DE1080CSI Notifications
                              c) 784 DE1101CLMT Notifications,
                              d) 12,869 DE4581s (no warrant attached),
                              e) 5,422 Message stubs (no warrant attached),
                              f) 26,000 Warrants (majority have 4581s attached,
                              all have message stubs),
                              g) 10 DE8784s, and/or
                              h) 40 DE731s.
   415        Communication   The System must communicate ODPD Notification        IFACE106
              Style           Interface requests via FTP.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                           ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 69 of 159



6C.2.3.12         CalJOBS Systems Integration

To qualify for unemployment benefits, Claimants must follow certain work search
requirements including training, attendance at workshops, etc. The CCR System must have
the ability to integrate with CalJOBS to verify that the Claimant has an active resume.

6C.2.3.12.1         Interface Name: Validate Active Resume in CalJOBS

This interface/integration allows the CCR System to verify that Claimant has an active
resume in CalJOBS. It is assumed that SSN or other identifier will be used.

6C.2.3.12.2         Validate Active Resume in CalJOBS System and Interface Characteristics
            Information Category                                            Description
Application or System Receiving or               CCR System
Requesting Data/Services
Receiving or Requesting Subsystem or Use         Use Case - Certify for Benefits
Case
Application or System Providing the Data         CalJOBS
Providing Subsystem or Use Case                  None
External System Architecture                     AIX, Informix DB
Assumed Integration Interface                    ODBC
Interface Complexity                             Simple
Data Transformation                              None
Programming Required on Legacy or Service        None
Provider Application
Availability of External System                  The CalJOBS System is available to accept and process
                                                 Validate Active Resume in CalJOBS Information requests seven
                                                 (7) days a week, 24 hours per day.



6C.2.3.12.3         Validate Active Resume in CalJOBS Integration Requirements
                                                                                                      Bidder
Requirement
                Context                                 Requirement                       State Use   Agrees
Number
                                                                                                      (Y/N)
    416        Integration         The Vendor must develop an interface to CalJOBS        IFACE107
               Needs               to check for the presence and status of Claimant‘s
                                   resume.
    417        Daily Volume        The System must support a minimum of 35,000            IFACE108
               /Load               Validate Active Resume in CalJOBS transactions
                                   per day.
    418        Peak Hour           The System must support a minimum of 5,000             IFACE109
               Messaging           Validate Active Resume in CalJOBS transactions at
               Volume              peak hour.



1673D445-8846-415B-9B58-82958E8C824D.DOC                                                  ADDENDUM 3            APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                      RFP OSI 7100-181
UIMOD PROJECT                                           SECTION 6C — PAGE 70 of 159


                                                                                          Bidder
Requirement
              Context                          Requirement                    State Use   Agrees
Number
                                                                                          (Y/N)
   419        Communication   The System must communicate Validate Active     IFACE110
              Style           Resume in CalJOBS requests via message queue.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                      ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 71 of 159



6C.2.3.13         PASS/ACES Systems Integration

The CCR System must have the ability to integrate with PASS/ACES to verify that the
Claimant has met the work search requirements (or attended the workshop).

6C.2.3.13.1         Interface Name: Validate Workshop Attendance or Lookup Appointment

The Integration will ensure that the CCR System can access PASS/ACES to validate
workshop attendance or to lookup appointment.

6C.2.3.13.2         Validate Workshop Attendance or Lookup Appointment;
                    System and Interface Characteristics
           Information Category                                          Description
Application or System Receiving or             CCR System
Requesting Data/Services
Receiving or Requesting Subsystem or           Use Case - Manage Claimant Account
Use Case
                                               Use Case - Update Eligibility Information
                                               Use Case - Certify for Benefits
                                               Use Case - Customer Service
Application or System Providing the Data       Program Activity Support System (PASS)
Providing Subsystem or Use Case                Activity Calendar and Event Scheduler (ACES)
External System Architecture                   AIX, Informix DB
Assumed Integration Interface                  ODBC Drivers
Interface Complexity                           Simple
Data Transformation                            None
Programming Required on Legacy or              None
Service Provider Application
Availability of External System                The PASS/ACES System is available to accept and process
                                               Validate Workshop Attendance or Lookup Appointment requests
                                               seven (7) days a week, 24 hours per day.



6C.2.3.13.3         Validate Workshop Attendance or Lookup Appointment Integration
                    Requirements
                                                                                                       Bidder
Requirement
                Context                               Requirement                          State Use   Agrees
Number
                                                                                                       (Y/N)
    420        Integration        The System must have the ability to integrate with       IFACE111
               Needs              PASS/ACES to verify that the Claimant has met the
                                  work search requirements (or attended the
                                  workshop).




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                   ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                       RFP OSI 7100-181
UIMOD PROJECT                                            SECTION 6C — PAGE 72 of 159


                                                                                          Bidder
Requirement
              Context                           Requirement                   State Use   Agrees
Number
                                                                                          (Y/N)
   421        Daily Volume    The System must support a minimum of 1000       IFACE112
              /Load           Validate Workshop Attendance or Lookup
                              Appointment transactions a day.
   422        Peak Hour       The System must support a minimum of 100        IFACE113
              Messaging       Validate Workshop Attendance or Lookup
              Volume          Appointment transactions at peak hour.
   423        Communication   The System must communicate Validate Workshop   IFACE114
              Style           Attendance or Lookup Appointment requests via
                              message queue.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                      ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 73 of 159



6C.2.3.14         EDDCOMM Systems Integration
The integration requires that there be a URL link between EDDCOMM and CCR System
Portals.

  6C.2.3.14.1       Interface Name: EDDCOMM – CCR System Link
This integration requires linking the EDDCOMM portal with the CCR System‘s Web site
(most likely through an embedded link).

  6C.2.3.14.2       EDDCOMM – CCR System Link – System and Interface Characteristics
         Information Category                                          Description
Application or System Receiving or        EDDCOMM
Requesting Data/Services
Receiving or Requesting Subsystem         EDDCOMM Web Portal
or Use Case
Application or System Providing the       CCR System
Data
Providing Subsystem or Use Case           CCR Web site
External System Architecture              Web Portal
Assumed Integration Interface             HTTP URL Link
Interface Complexity                      Simple
Data Transformation                       None
Programming Required on Legacy or         None
Service Provider Application



  6C.2.3.14.3       EDDCOMM-CCR System Link Integration Requirement
                                                                                                 Bidder
Requirement
                Context                                 Requirement                  State Use   Agrees
Number
                                                                                                 (Y/N)
   424         Integration Needs      The System must be accessible via the          IFACE130
                                      EDDCOMM portal.
   425         Daily                  The System must support a minimum of 2000      IFACE131
               Volume/Load            EDDCOMM-CCR System Link transactions a day.
   426         Peak Hour              The System must support a minimum of 400       IFACE132
               Messaging              EDDCOMM-CCR System Link transactions at
               Volume                 peak hour.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                             ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 74 of 159



6C.2.3.15         Worker Profiling and Reemployment Services (Profiling) Systems
                   Integration
The CCR System must notify the Profiling system about changes to Claimant‘s residence
zip code and demographics.


6C.2.3.15.1         Interface Name: Update Profiling with Address Change

This interface/integration allows the CCR System to notify Profiling regarding the Claimant‘s
residence address change.

6C.2.3.15.2         Update Profiling with Address Change—System and Interface Characteristics
          Information Category                                          Description
Application or System Receiving or        Profiling
Requesting Data/Services
Receiving or Requesting Subsystem or      None
Use Case
Application or System Providing the       CCR System
Data
Providing Subsystem or Use Case           Use Case - Update Demographics
External System Architecture              Mainframe DB2
Assumed Integration Interface             ODBC Drivers
Interface Complexity                      Simple
Data Transformation                       None
Programming Required on Legacy or         None
Service Provider Application
Availability of External System           The Profiling System is available to accept and process Update
                                          Profiling with Address Change requests seven (7) days a week, 24
                                          hours per day.



6C.2.3.15.3         Update Profiling with Address Change Integration Requirements
                                                                                                     Bidder
Requirement
                Context                               Requirement                       State Use    Agrees
Number
                                                                                                     (Y/N)
    427        Integration        The System must provide an interface to the           IFACE133
               Needs              Profiling system for update of Claimant‘s residence
                                  address.
    428        Daily Volume       The System must support a minimum of 10,000           IFACE134
               /Load              Update Profiling with Address Change transactions
                                  a day.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                ADDENDUM 3            APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                         RFP OSI 7100-181
UIMOD PROJECT                                              SECTION 6C — PAGE 75 of 159


                                                                                              Bidder
Requirement
              Context                            Requirement                      State Use   Agrees
Number
                                                                                              (Y/N)
   429        Peak Hour       The System must support a minimum of 1,000          IFACE135
              Messaging       Update Profiling with Address Change transactions
              Volume          at peak hour.
   430        Communication   The System must communicate Update Profiling        IFACE136
              Style           with Address Change requests via message queue.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                          ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 76 of 159



The CCR System must notify the Profiling system about Claimant‘s first payment.

6C.2.3.15.4         Interface Name: Update Profiling First Payment Information

This interface/integration allows the CCR System to notify the Profiling system with First
Payment Information.

6C.2.3.15.5         Update Profiling First Payment Information—System and Interface
                    Characteristics
          Information Category                                           Description
Application or System Receiving or          Profiling
Requesting Data/Services
Receiving or Requesting Subsystem or        None
Use Case
Application or System Providing the         CCR System
Data
Providing Subsystem or Use Case             Use Case - Initiate Payment Distribution
External System Architecture                Mainframe DB2
Assumed Integration Interface               ODBC Drivers
Interface Complexity                        Simple
Data Transformation                         None
Programming Required on Legacy or           None
Service Provider Application
Availability of External System             The Profiling System is available to accept and process Update
                                            Profiling First Payment Information requests seven (7) days a week,
                                            24 hours per day.



6C.2.3.15.6         Update Profiling First Payment Information Integration Requirements
                                                                                                         Bidder
Requirement
                Context                                 Requirement                        State Use     Agrees
Number
                                                                                                         (Y/N)
    431         Integration           The System must provide an interface to the
                Needs                 Profiling system for update of first payment         IFACE137
                                      information.
    432         Daily Volume          The System must support a minimum of 28,000
                /Load                 Update Profiling First Payment Information           IFACE138
                                      transactions a day.
    433         Peak Hour             The System must support a minimum of 3,000
                Messaging             Update Profiling First Payment Information           IFACE139
                Volume                transactions at peak hour.
    434         Communication         The System must communicate Update Profiling
                Style                 First Payment Information requests via message       IFACE140
                                      queue.

1673D445-8846-415B-9B58-82958E8C824D.DOC                                                   ADDENDUM 3             APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                  RFP OSI 7100-181
UIMOD PROJECT                                       SECTION 6C — PAGE 77 of 159




6C.2.3.16           Section Deleted
                                                                                     Bidder
Requirement
                                      Requirement                        State Use   Agrees
Number
                                                                                     (Y/N)
   435        Requirement Deleted                                                     N/A




1673D445-8846-415B-9B58-82958E8C824D.DOC                                 ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 78 of 159



6C.3 POLICY AND REGULATION
The UIMOD Project is governed by policies and regulations of the State of California as
follows:
     1. Network standards for equipment, access, and security are governed by the
        policies of the DTS and EDD.
     2. Equipment and security standards for data, site security, data security, server
        naming, and server room standards are governed by polices of the EDD and the
        DTS.
     3. The Single Client Database is a mainframe application housed and operated by the
        DTS. Policies regarding system and data access to that system are governed by
        the DTS policy.
     4. Public policies such as the Dymally-Alatorre Bilingual Services Act, Title 22, and UI
        regulations.


6C.3.1        Policy and Regulation Requirements
                                                                                                 Bidder
Requirement
                                          Requirement                                State Use   Agrees
Number
                                                                                                 (Y/N)
   436        To comply with the Bilingual Services Act of 1977 (Dymally-Alatorre)   SUPP546
              the CCR System external user interfaces must support multiple
              languages. (Currently services must be provided in English and
              Spanish.)
   437        The CCR System must provide the ability to support additional          SUPP547
              languages as necessary.
   438        The CCR System must support ADA (Americans with Disabilities Act)      SUPP548
              requirements (e.g. readers for the blind).
   439        The CCR System must comply with Title 22, CUIC, California             SUPP550
              Government Code, DOL, Code of Federal Regulations, U.S. Code.
   440        The CCR System must comply with Federal Section 508.                   SUPP854
   441        The CCR System must comply with Ca Gov Code 11135.                     SUPP855




1673D445-8846-415B-9B58-82958E8C824D.DOC                                             ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                                                                                     RFP OSI 7100-181
UIMOD PROJECT                                                                                                          SECTION 6C — PAGE 79 of 159



6C.4                       REPORTING / BUSINESS INTELLIGENCE REPORTING
                           REQUIREMENTS
The EDD requires standardized reports and ad hoc reporting that will facilitate good
management of the Unified Call Distribution (UCD) system and the UI program.
Note: In the requirements, the UCD system includes the functionality for the call routing, the
IVR functionality, telephone and the skills based routing.
Both the UCD system and the CCR System must include a facility for exporting information
to an external, common ―UI Data Warehouse‖.



                                                    Operational Reporting and Business Intelligence Environment

                        Real Time
                       Monitoring and
                         Reporting



                                                                                                           Data Server
                                                                                                         SAS Partitioned Data
                                                                                                               Server
           UCD                                                                                                (SPDS)




                                                                                                                                             Reports, Query,
           SCDB                                                                                                                               and Analytics
         (UIS/DIS)                                                                                                                            Enterprise Business
                                                                                                                                               Intelligence (EBI),
                                                                                                                                                Enterprise Guide
                                                                                                                                                       (EG),               UI
                                                                                                                                                SAS Foundation           Branch

                                                                                                                                               Data Mining
                                                                                                                                             Enterprise Miner (EM)
        Base Wage
                                    ETL                                                                         ETL
                                   Enterprise                         Data                                    Enterprise
                                                                                                                                                   OLAP
                                     Data                            Quality               Data                 Data                          Enterprise Business
                                                Staging Area                                                                                   Intelligence (EBI)
                                  Integration                       (Data Flux)        Warehouse             Integration         Data Mart
                                     (EDI)      (BICC SAN)                                                      (EDI)
                                                                                       (BICC SAN)                               (BICC SAN)       Balanced               Program
                                                                                                                                                 Scorecard            Review Branch
                                                                                                                                             Strategic Performance
          WBCF                                                                                                                                Management (SPM)

                                                                                                                                                Forecasting
                                                                                                                                              Econometric Time
                                                                                                                                                Series (ETS)




            TAS

                                                                                  Metadata




          CalJobs




       External Data



     Operational Systems                                       Business Intelligence Competency Center System                                                         Constituencies




    Figure 6C1: Operational Reporting and Business Intelligence Environment
Contractors should be able to produce, at a minimum, reports equivalent to those produced
today by the current System. In addition, Contractors must have capabilities within their
proposed solutions to produce reports desired by EDD in the future; i.e., the capability to
produce a desired report may be included in Mandatory Qualifications enumerated below.
Some reports listed will require information from a source other than the UCD and the CCR


1673D445-8846-415B-9B58-82958E8C824D.DOC                                                                                                                             ADDENDUM 3        APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                       RFP OSI 7100-181
UIMOD PROJECT                                            SECTION 6C — PAGE 80 of 159



System. Data from all required sources will be combined and managed in a centralized data
warehouse and available for usage by the UI program.
Reports should be accessible from any management workstation in any location. Whether
in UI Call Centers or in the UI Central Office, users will utilize reports for:
            1.   Real Time Information,
            2.   Day-to-Day Management,
            3.   Business Planning Information, and
            4.   Decision Support.

A number of the requirements in the sections below are related to the construction of an
Enterprise Data Warehouse. These requirements are ―Mandatory/Optional‖ – it is
mandatory that the bidder respond and provide cost estimates, but it is the UIMOD project‘s
option to include these requirements in the scope of the project.

The EDD is in the process of constructing an enterprise data warehouse that may be
operational in time for the UIMOD project to utilize. The UIMOD Contractor may just
need to develop data marts and reports, not develop the data warehouse that will
supply the data marts.

EDD has purchased enterprise licenses for the following products:

     SAS Enterprise Miner
     SAS Foundation
     SAS STAT
     SAS Data Integration with Database Access Engines
     SAS Business Intelligence Server (SAS BI Server)
     SAS Microsoft Office Add-in
     SAS Strategic Performance Management
     SAS Scaleable Performance Data Server
     Data Flux
     Platform Suite for SAS
     Microsoft Reporting Services

For custom end-user reporting development, the UIMOD Contractor may choose
between Microsoft Reporting Services and the SAS BI Server products.

The Bidder will be required to use the products listed above for any Business Intelligence
related solutions. EDD possesses sufficient licenses for the all of the above products, with
the exception of Microsoft Reporting Services and the Data Flux product line. If the Bidder
chooses to use these products, additional licenses will need to be acquired at the Bidders
expense.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                         ADDENDUM 3    APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                         RFP OSI 7100-181
UIMOD PROJECT                                              SECTION 6C — PAGE 81 of 159



6C.4.1        Real Time Information
The EDD UI Central Office utilizes Real Time Information reports to:
     1. Manage to meet EDD's business objectives right now.
     2. Manage to established priorities.
     3. Manage call routing around call types and call volumes.
     4. Manage call routing around types of calls coming in.
     5. Manage call routing around functional needs.
     6. Troubleshoot problems.
     7. Maintain availability of UCD system Statewide.
     8. Maintain access in accordance with policy for people calling into UCD system.
     9. Monitor that equipment and systems are working properly / at optimum levels.


6C.4.2        Day-to-Day Management
The EDD UI Central Office utilizes Day-to-Day Management Information reports to:
     1. Determine the call demand.
     2. Determine UCD system usage versus capacity.
     3. Manage resources.
     4. Maintain health of the UCD system.
     5. Compare historical view to present view.
     6. Manage to meet EDD's business objectives.
     7. Manage to established priorities.
     8. Manage staff time around call types and call volumes.
     9. Manage skills of staff around types of calls coming in.
     10. Manage skills of staff around functional needs.
     11. Analyze performance against DLA requirements.


6C.4.3        Business Planning Information
The EDD UI Central Office utilizes Business Planning Information reports to:
     1. Keep equipment current to maintain level of service.
     2. Meet the various workloads in UIB (managing the fiscal year workload).
     3. Plan, including long-term resource planning.


1673D445-8846-415B-9B58-82958E8C824D.DOC                                        ADDENDUM 3   APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 82 of 159



     4. Provide long-term maintenance and support.
     5. Maintain journal entry reporting.

The EDD UI Call Centers utilize Business Planning Information reports to:
     1. Ensure that "right" staff (numbers and skills mix) is on-board to meet Statewide
        objectives.
     2. Manage balance between phone work and non-phone work, and still meet service
        goals.
     3. Plan for training and leaves.
     4. Manage a multi-functional environment.


6C.4.4        Decision Support Information
The EDD UI Central Office utilizes Decision Support Information reports to:

     1. Obtain information quickly and easily to support analyses for decision-making at all
        levels of the organization.

The section below describes the requirements for the tools needed for the new environment
and how it will be accessed, administered and monitored, and how data will be managed.

6C.4.5        Business Intelligence and Reporting: Tools Requirements
                                                                                                      Bidder
Requirement
                                             Requirement                                  State Use   Agrees
Number
                                                                                                      (Y/N)
   442        Requirement Deleted                                                                       N/A

   443        Requirement Deleted                                                                      N/A

   444        User must have the ability to define the ―time-slices‖ for reports in the   FCTN756
              real-time window.
   445        Requirement Deleted                                                                      N/A

   446        Requirement Deleted                                                                      N/A

   447        Requirement Deleted                                                                      N/A

   448        Requirement Deleted                                                                      N/A

   449        The System must allow user to initiate printing of reports and queries.     FCTN1146
   450        The Dashboard Report must permit drill-down analysis by                     FCTN1158
              organizational entity.
   451        The System must allow existing reports or ad hoc reports to be re-          FCTN1300
              useable for presentation of similar but different information.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                  ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 83 of 159


                                                                                                  Bidder
Requirement
                                           Requirement                                State Use   Agrees
Number
                                                                                                  (Y/N)
   452        Mandatory/Optional                                                      FCTN1305
              The CCR System must provide for secure data extraction using
              authentication and access control from the CCR to System Data
              Warehouse using EDD ETL tools to produce specialized subsets of
              data for use with data mining tools.
   453        Requirement Deleted                                                                  N/A

   454        Mandatory/Optional                                                      SUPP604
              The Data Warehouse must include administration tools that support
              data usage auditing.
   455        Mandatory/Optional                                                      SUPP605
              The Data Warehouse must include administration tools that support
              business information and model maintenance.
   456        Mandatory/Optional                                                      SUPP606
              The Data Warehouse must include administration tools that support
              security control (authentication and access management).
   457        Mandatory/Optional                                                      SUPP608
              The Data Warehouse must include administration tools that support
              query cataloging.
   458        Mandatory/Optional                                                      SUPP609
              The Data Warehouse must include administration tools that support
              creating, updating, and deleting data extracts from the production
              environment into the Data Warehouse.
   459        Mandatory/Optional                                                      SUPP610
              The Data Warehouse must include administration tools that support
              backups.
   460        Mandatory/Optional                                                      SUPP611
              The Contractor must implement instrumentation and tools to monitor
              query performance.
   461        Requirement Deleted                                                                  N/A

   462        Requirement Deleted                                                                  N/A

   463        Requirement Deleted                                                                  N/A

   464        Requirement Deleted                                                                  N/A

   465        Mandatory/Optional                                                      SUPP616
              The CCR System must support incremental loading of data into the
              Data Warehouse based on changes to the CCR System and other
              databases.
   466        Mandatory/Optional                                                      SUPP618
              The CCR System must include a standardized Web-based reporting
              tool to allow authorized users to access standardized reports, and to
              create and publish ad-hoc reports, over the Web.
   467        For custom, end-user, reporting needs, the Prime Contractor must        SUPP644
              deliver solutions based on Microsoft Reporting Services or SAS BI
              Server, or the equivalent product from Microsoft or SAS that is
              available at the time of contract award.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                              ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 84 of 159


                                                                                                   Bidder
Requirement
                                             Requirement                               State Use   Agrees
Number
                                                                                                   (Y/N)
   468        Mandatory/Optional                                                       SUPP652
              The Data Warehouse must include administration tools that support
              meta data management for maintenance of reference data,
              independent of business intelligence and reporting tools. For example,
              the final solution must allow the EDD definition for "unpaid weeks" to
              be standardized across all reports and shared by all reporting users.
   469        Mandatory/Optional                                                       SUPP654
              The Data Warehouse must include administration tools that allow the
              publishing of new reports, and in such a way that only authorized
              users are allowed access.
   470        The reporting system must restrict access to reports, data or other      SUPP849
              reporting resources according to the authorization level assigned to
              the requestor.

   471        Mandatory/Optional                                                       SUPP853
              The Contractor shall ensure that construction and usage of the
              Business Intelligence solution, in regards to data confidentiality,
              integrity, and availability conforms to:
              a) the security requirements of FIPS-200,
              b) SAM 4841.2 through SAM 4841, and
              c) State Budget Letter 05-08.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                               ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 85 of 159



Performance and other constraining requirements on the Business Intelligence and
reporting environment are included below.

6C.4.6        Business Intelligence and Reporting: Constraining Requirements
                                                                                                   Bidder
Requirement
                                           Requirement                                 State Use   Agrees
Number
                                                                                                   (Y/N)
   472        Requirement Deleted                                                                   N/A
   473        Mandatory/Optional                                                       FCTN748
              The System must have the ability to support at least 100 concurrent
              users. This includes, but is not limited to, real time monitoring and
              running of historical reports.
   474        Requirement Deleted                                                                   N/A

   475        Requirement Deleted                                                                   N/A

   476        Reports must be accessible from any management workstation in any        FCTN873
              location.
   477        Mandatory/Optional                                                       FCTN1215
              The System must retain at least three (3) years of data beginning with
              the start up of the first call center.
   478        Mandatory/Optional                                                       FCTN1302
              The System must make the most recent three (3) years of continued
              claims archive retrieval functionality for ad-hoc data reporting.
   479        Mandatory/Optional                                                       FCTN1303
              The System must save summarized information for a configurable
              period of time, and make this summary information available in the
              business intelligence reporting environment.
   480        Requirement Deleted                                                                   N/A
   481        Mandatory/Optional                                                       SUPP600
              The CCR System must include a business intelligence and reporting
              environment that is separate from the production environment to
              support business reporting.
   482        Mandatory/Optional                                                       SUPP603
              The data models in the data warehouse must be structured for
              reusability.
   483        Mandatory/Optional                                                       SUPP617
              Claimant related data in the Data Warehouse must be refreshed daily,
              at a minimum.
   484        The CCR System must include a reporting environment optimized for        SUPP655
              reporting and analysis of claimant payment data. Ninety percent
              (90%) of reports must respond in under 30 seconds.
   484A       Mandatory/Optional                                                       SUPP863
              The CCR System Data Warehouse must be housed within EDD
              facilities.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                               ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 86 of 159


                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   484B       For all proposed Business Intelligence solutions the Contractor must      SUPP866
              use products from the following list:
                   SAS Enterprise Miner
                   SAS Foundation
                   SAS STAT
                   SAS Data Integration with Database Access Engines
                   SAS BI Server
                   SAS Strategic Performance Management
                   SAS Scaleable Performance Data Server
                   Data Flux
                   Platform Suite for SAS
                   Microsoft Reporting Services

              EDD possesses sufficient licenses for the Contractor for all of the
              above products, with the exception of Microsoft Reporting Services
              and the Data Flux product line.



6C.4.7        Business Intelligence and Reporting: Ad-hoc Reporting
              Requirements
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   485        Requirement Deleted                                                                    N/A
   486        Requirement Deleted                                                                    N/A
   487        Requirement Deleted                                                                    N/A
   488        Requirement Deleted                                                                    N/A
   489        Requirement Deleted                                                                    N/A
   490        Requirement Deleted                                                                    N/A
   491        Requirement Deleted                                                                    N/A
   492        Requirement Deleted                                                                    N/A
   493        The System must produce a report providing the number of                  FCTN829
              abandoned certifications (with subsequent completed certification).
   494        All data elements used or needed to create the various reports must       FCTN872
              be accessible for use even though they may not be included in a
              standard report template.
   495        The System must allow reports to be created from a pre defined set of     FCTN1144
              data elements.
   496        The CCR System reports must be developed with parameterized input         FCTN1299
              fields to make the report flexible for reporting variations of the same
              information from different vantage points (e.g. payments by zip
              between specific dates.)


1673D445-8846-415B-9B58-82958E8C824D.DOC                                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 87 of 159


                                                                                                      Bidder
Requirement
                                            Requirement                                   State Use   Agrees
Number
                                                                                                      (Y/N)
   497        Requirement Deleted                                                                      N/A
   498        The CCR System must include a reporting environment for Claimant            SUPP653
              payment data that facilitates analysis. (Including, for example, analysis
              by year, by month, by day, by claimant zip code, and by other
              demographic parameters).




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                  ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 88 of 159



In addition to reports that can be created and managed by the UIMOD system users, there
still exists a need for standard system reports to be run that will be created by the Contractor
to meet existing business needs. These requirements are included below.

6C.4.8        Business Intelligence and Reporting: Standard Reporting
              Requirements
                                                                                                Bidder
Requirement
                                           Requirement                              State Use   Agrees
Number
                                                                                                (Y/N)
   499        The System must maintain weekly agent Trace Reports equivalent for    FCTN751
              one month (instead of current two weeks).
   500        The System must report on service levels related to EDD‘s strategic   FCTN752
              goals on timeliness of service.
   501        Requirement Deleted                                                                  N/A
   502        Requirement Deleted                                                                  N/A
   503        Requirement Deleted                                                                  N/A
   504        Requirement Deleted                                                                  N/A
   505        Requirement Deleted                                                                  N/A
   506        Requirement Deleted                                                                  N/A
   507        Requirement Deleted                                                                  N/A
   508        Requirement Deleted                                                                  N/A
   509        Requirement Deleted                                                                  N/A
   510        Requirement Deleted                                                                  N/A
   511        Requirement Deleted                                                                  N/A
   512        Requirement Deleted                                                                  N/A
   513        Requirement Deleted                                                                  N/A
   514        Requirement Deleted                                                                  N/A
   515        Requirement Deleted                                                                  N/A
   516        Requirement Deleted                                                                  N/A
   517        Requirement Deleted                                                                  N/A
   518        Requirement Deleted                                                                  N/A
   519        Requirement Deleted                                                                  N/A
   520        Requirement Deleted                                                                  N/A
   521        Requirement Deleted                                                                  N/A
   522        Requirement Deleted                                                                  N/A
   523        Reports must be available in batch mode as scheduled reports.         FCTN870
   524        ‘Requirement Deleted                                                                 N/A




1673D445-8846-415B-9B58-82958E8C824D.DOC                                            ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
UIMOD PROJECT                                                     SECTION 6C — PAGE 89 of 159


                                                                                                        Bidder
Requirement
                                             Requirement                                    State Use   Agrees
Number
                                                                                                        (Y/N)
   525        The System must provide a dashboard to allow managers to have                 FCTN1145
              real-time or near real-time information pre defined sets of core
              operational data elements (e.g. assembly line information for real-time
              resource management and workload management.).
   526        The System must provide on-line ―dashboard‖ style report that reports         FCTN1153
              claimant quality attributes including but not limited to the number of
              hang ups (phone and IVR), percent of continued claims rejected,
              customer service inquiries for continued claims, first payment time
              lapse (FPTL), continued claims time lapse (CCPTL), oldest FPTL,
              oldest CCPTL, customer service wait time.
   527        The System must provide a Dashboard Report that reports                       FCTN1154
              taxpayer/employer quality attributes including administrative
              cost/payments, transactions rejected due to potential fraud,
              overpayments/total payments, disqualifications/continued claims;
              appeals/continued claims.
   528        The System must provide a Dashboard Report that reports EDD                   FCTN1155
              management quality attributes including unprocessed continued
              claims, abandoned transactions (Web and IVR), rework rate
              (adjustments caused by Department error/total continued claims),
              administrative cost/total cost, labor cost per claim dollar, labor cost per
              continued claims, average duration, overtime.
   529        The System must provide a Dashboard Report that reports EDD                   FCTN1156
              associate staff person quality attributes including average call time in
              customer service, rework rate, number of re issues, number of
              customer service inquiries for continued claims.
   530        The Dashboard Report must be an on-line report that shows daily,              FCTN1157
              month-to-date and year-to-date totals, and moving average for last 30,
              90 and 360 days.
   531        Standard reports must be accessible via the EDD portal infrastructure.        SUPP619




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                    ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 90 of 159



The Data Warehouse must provide a complete set of data, accompanied by information to
help end-users find the data they need. The requirements below describe the different types
of data needed, as well as attributes of data being managed.

6C.4.9        Business Intelligence and Reporting: Data Requirements
                                                                                                   Bidder
Requirement
                                          Requirement                                  State Use   Agrees
Number
                                                                                                   (Y/N)
   532        Requirement Deleted                                                                   N/A
   533        Requirement Deleted                                                                   N/A
   534        Requirement Deleted                                                                   N/A
   535        Requirement Deleted                                                                   N/A
   536        Requirement Deleted                                                                   N/A
   537        The System must produce a report providing number of calls to            FCTN827
              certification pathway / application.
   538        The System must produce a report providing number of certifications      FCTN828
              attempted and completed by half hour within a 24-hour period.
   539        The System must produce a report providing the number of                 FCTN830
              abandoned certifications (without subsequent completed certification).
   540        The System must produce a report providing the number of                 FCTN831
              certifications with agent involvement.
   541        The System must produce a report providing certification length in       FCTN832
              seconds, including average, shortest, and longest.
   542        The System must produce a report providing time per question in          FCTN833
              seconds, including average, shortest, and longest.
   543        The System must produce a report providing number of times the           FCTN834
              ―help‖ feature is invoked (per question and per certification).
   544        The System must produce a report providing the number of ―out-of-        FCTN835
              patterns‖ (per question and per certification).
   545        The System must produce a report providing counts of ―bail outs‖ at      FCTN836
              each menu location.
   546        The System must produce a report providing length of time (in            FCTN837
              seconds) until claimant ―bailed out.‖
   547        The System must produce a report with the number of early and late       FCTN838
              certification attempts.
   548        The system must produce a report providing the number of BX‘d and        FCTN839
              BYE certification attempts.
   549        The System must produce a report providing the number of                 FCTN840
              successfully authenticated claimants.
   550        The System must produce a report providing the number of                 FCTN841
              unsuccessfully authenticated claimants.



1673D445-8846-415B-9B58-82958E8C824D.DOC                                               ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 91 of 159


                                                                                                      Bidder
Requirement
                                            Requirement                                   State Use   Agrees
Number
                                                                                                      (Y/N)
   551        The System must produce a report providing the number of claimants          FCTN842
              attempting to certify without claim or client record on file (capture ANI
              and add to ―hot list‖ if no claim filed within a specified number of
              days).
   552        Requirement Deleted                                                                      N/A
   553        Requirement Deleted                                                                      N/A
   554        The System must produce a report providing the number of calls per          FCTN845
              SSN per day / week / month.
   555        The System must provide the capability to correlate certification with      FCTN846
              North American Industry Classification System (NAICS), education,
              last employer, zip code, race, time/date certification filed, and other
              demographic information, as needed.
   556        Requirement Deleted                                                                      N/A
   557        The System must be able to produce the information to report on             FCTN1147
              claimant responses on continued claims that resulted in processed
              claims and claims that required intervention.
   558        Requirement Deleted                                                                      N/A
   559        The System must be able to produce the information to report on             FCTN1149
              continued claims transaction volumes.
   560        The System must be able to produce the information to report on the         FCTN1150
              number of continued claims processed by each organizational entity
              and staff member.
   561        The System must be able to produce the information to report on the         FCTN1151
              numbers of claimants by demographic profile (such as address,
              phone number, language), channel used to certify for benefits and the
              disposition of the continued claim certification.
   562        The System must be able to produce the information to report on the         FCTN1152
              numbers and types of issues that resulted in clarification, by staff
              person that recorded the issue and by the staff person that resolved
              the issue.
   563        The Dashboard Report must be able to show all results for a                 FCTN1159
              particular organizational entity.
   564        The System must be able to produce the information to report on             FCTN1301
              significant events that affected the workload volume and quality.
   565        The System must be able to produce the information for reports on           FCTN1304
              operational activities.
   566        The System must allow authorized staff to enter significant event           FCTN1312
              information that can be associated with claim activity to assist in
              drawing correlations between specific events and workload volume
              and quality.
   567        The reporting system must use one data element for every function.          SUPP18
              Each data element will be unique and always appear the same when
              reported.


1673D445-8846-415B-9B58-82958E8C824D.DOC                                                  ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 92 of 159


                                                                                                  Bidder
Requirement
                                           Requirement                                State Use   Agrees
Number
                                                                                                  (Y/N)
   568        Mandatory/Optional                                                      SUPP601
              The Contractor must develop and implement all critical interfaces to
              extract data from the various operational systems and import the data
              to the CCR System Data Warehouse.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                              ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                RFP OSI 7100-181
UIMOD PROJECT                                     SECTION 6C — PAGE 93 of 159




6C.5 CCNPAU REQUIREMENTS (CALNET 2)

6C.5.1        CALNET 2 and CCNPAU

   Due to the CALNET 2 contract most of the UIMOD RFP requirements related to
   CCNPAU subproject have been removed.


6C.5.2        Section Deleted

6C.5.3        Section Deleted

6C.5.4        Section Deleted
Table 6C.1 Table Deleted

6C.5.4.1      Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   569        Requirement Deleted                                                   N/A
   570        Requirement Deleted                                                   N/A
   571        Requirement Deleted                                                   N/A
   572        Requirement Deleted                                                   N/A
   573        Requirement Deleted                                                   N/A



6C.5.5        Section Deleted

6C.5.5.1       Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   574        Requirement Deleted                                                   N/A
   575        Requirement Deleted                                                   N/A
   576        Requirement Deleted                                                   N/A




1673D445-8846-415B-9B58-82958E8C824D.DOC                               ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                RFP OSI 7100-181
UIMOD PROJECT                                     SECTION 6C — PAGE 94 of 159



Table 6C.2 Table Deleted


6C.5.6        Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   577        Requirement Deleted                                                   N/A
   578        Requirement Deleted                                                   N/A
   579        Requirement Deleted                                                   N/A
   580        Requirement Deleted                                                   N/A
   581        Requirement Deleted                                                   N/A
   582        Requirement Deleted                                                   N/A
   583        Requirement Deleted                                                   N/A
   584        Requirement Deleted                                                   N/A
   585        Requirement Deleted                                                   N/A



6C.5.7        Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   586        Requirement Deleted                                                   N/A
   587        Requirement Deleted                                                   N/A
   588        Requirement Deleted                                                   N/A
   589        Requirement Deleted                                                   N/A



6C.5.8        Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   590        Requirement Deleted                                                   N/A
   591        Requirement Deleted                                                   N/A
   592        Requirement Deleted                                                   N/A
   593        Requirement Deleted                                                   N/A
   594        Requirement Deleted                                                   N/A




1673D445-8846-415B-9B58-82958E8C824D.DOC                               ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                RFP OSI 7100-181
UIMOD PROJECT                                     SECTION 6C — PAGE 95 of 159



6C.5.9        Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   595        Requirement Deleted                                                   N/A
   596        Requirement Deleted                                                   N/A
   597        Requirement Deleted                                                   N/A
   598        Requirement Deleted                                                   N/A
   599        Requirement Deleted                                                   N/A
   600        Requirement Deleted                                                   N/A
   601        Requirement Deleted                                                   N/A
   602        Requirement Deleted                                                   N/A
   603        Requirement Deleted                                                   N/A
   604        Requirement Deleted                                                   N/A
   605        Requirement Deleted                                                   N/A
   606        Requirement Deleted                                                   N/A
   607        Requirement Deleted                                                   N/A
   608        Requirement Deleted                                                   N/A
   609        Requirement Deleted                                                   N/A
   610        Requirement Deleted                                                   N/A
   611        Requirement Deleted                                                   N/A
   612        Requirement Deleted                                                   N/A
   613        Requirement Deleted                                                   N/A
   614        Requirement Deleted                                                   N/A
   615        Requirement Deleted                                                   N/A
   616        Requirement Deleted                                                   N/A
   617        Requirement Deleted                                                   N/A
   618        Requirement Deleted                                                   N/A
   619        Requirement Deleted                                                   N/A
   620        Requirement Deleted                                                   N/A
   621        Requirement Deleted                                                   N/A
   622        Requirement Deleted                                                   N/A
   623        Requirement Deleted                                                   N/A
   624        Requirement Deleted                                                   N/A
   625        Requirement Deleted                                                   N/A
   626        Requirement Deleted                                                   N/A


1673D445-8846-415B-9B58-82958E8C824D.DOC                               ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                RFP OSI 7100-181
UIMOD PROJECT                                     SECTION 6C — PAGE 96 of 159


                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   627        Requirement Deleted                                                   N/A
   628        Requirement Deleted                                                   N/A
   629        Requirement Deleted                                                   N/A
   630        Requirement Deleted                                                   N/A
   631        Requirement Deleted                                                   N/A
   632        Requirement Deleted                                                   N/A
   633        Requirement Deleted                                                   N/A
   634        Requirement Deleted                                                   N/A
   635        Requirement Deleted                                                   N/A
   636        Requirement Deleted                                                   N/A
   637        Requirement Deleted                                                   N/A
   638        Requirement Deleted                                                   N/A
   639        Requirement Deleted                                                   N/A
   640        Requirement Deleted                                                   N/A
   641        Requirement Deleted                                                   N/A
   642        Requirement Deleted                                                   N/A
   643        Requirement Deleted                                                   N/A
   644        Requirement Deleted                                                   N/A
   645        Requirement Deleted                                                   N/A
   646        Requirement Deleted                                                   N/A
   647        Requirement Deleted                                                   N/A
   648        Requirement Deleted                                                   N/A
   649        Requirement Deleted                                                   N/A
   650        Requirement Deleted                                                   N/A
   651        Requirement Deleted                                                   N/A
   652        Requirement Deleted                                                   N/A
   653        Requirement Deleted                                                   N/A
   654        Requirement Deleted                                                   N/A
   655        Requirement Deleted                                                   N/A
   656        Requirement Deleted                                                   N/A




1673D445-8846-415B-9B58-82958E8C824D.DOC                               ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                RFP OSI 7100-181
UIMOD PROJECT                                     SECTION 6C — PAGE 97 of 159



6C.5.10       Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   657        Requirement Deleted                                                   N/A
   658        Requirement Deleted                                                   N/A



6C.5.11       Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   659        Requirement Deleted                                                   N/A
   660        Requirement Deleted                                                   N/A
   661        Requirement Deleted                                                   N/A
   662        Requirement Deleted                                                   N/A
   663        Requirement Deleted                                                   N/A
   664        Requirement Deleted                                                   N/A
   665        Requirement Deleted                                                   N/A
   666        Requirement Deleted                                                   N/A



6C.5.12       Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   667        Requirement Deleted                                                   N/A
   668        Requirement Deleted                                                   N/A
   669        Requirement Deleted                                                   N/A
   670        Requirement Deleted                                                   N/A
   671        Requirement Deleted                                                   N/A



6C.5.13       Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   672        Requirement Deleted                                                   N/A
   673        Requirement Deleted                                                   N/A
   674        Requirement Deleted                                                   N/A



1673D445-8846-415B-9B58-82958E8C824D.DOC                               ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                RFP OSI 7100-181
UIMOD PROJECT                                     SECTION 6C — PAGE 98 of 159


                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   675        Requirement Deleted                                                   N/A
   676        Requirement Deleted                                                   N/A
   677        Requirement Deleted                                                   N/A



6C.5.14       Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   678        Requirement Deleted                                                   N/A
   679        Requirement Deleted                                                   N/A
   680        Requirement Deleted                                                   N/A
   681        Requirement Deleted                                                   N/A



6C.5.15       Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   682        Requirement Deleted                                                   N/A
   683        Requirement Deleted                                                   N/A
   684        Requirement Deleted                                                   N/A



6C.5.16       Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   685        Requirement Deleted                                                   N/A
   686        Requirement Deleted                                                   N/A
   687        Requirement Deleted                                                   N/A



6C.5.17       Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   688        Requirement Deleted                                                   N/A
   689        Requirement Deleted                                                   N/A


1673D445-8846-415B-9B58-82958E8C824D.DOC                               ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                RFP OSI 7100-181
UIMOD PROJECT                                     SECTION 6C — PAGE 99 of 159


                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   690        Requirement Deleted                                                   N/A



6C.5.18       Section Deleted
                                                                                   Bidder
Requirement                         Requirement                        State Use   Agrees
Number                                                                             (Y/N)
   691        Requirement Deleted                                                   N/A
   692        Requirement Deleted                                                   N/A



6C.5.19       Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   693        Requirement Deleted                                                   N/A



6C.5.20       Section Deleted

Figure 6C2: Figure Deleted


6C.5.21       Section Deleted

6C.5.21.1     Section Deleted
6C.5.21.2     Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   694        Requirement Deleted                                                   N/A



6C.5.21.3     Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   695        Requirement Deleted                                                   N/A




1673D445-8846-415B-9B58-82958E8C824D.DOC                               ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 100 of 159



6C.5.21.4     Section Deleted
                                                                                                Bidder
Requirement
                                           Requirement                              State Use   Agrees
Number
                                                                                                (Y/N)
   696        Requirement Deleted                                                                N/A



6C.5.21.5     Section Deleted
                                                                                                Bidder
Requirement
                                           Requirement                              State Use   Agrees
Number
                                                                                                (Y/N)
   697        Requirement Deleted                                                                N/A



6C.5.21.6     Section Deleted
                                                                                                Bidder
Requirement
                                           Requirement                              State Use   Agrees
Number
                                                                                                (Y/N)
   698        Requirement Deleted                                                                N/A



6C.5.21.7     Computer Telephone Integration (CTI) Applications
The current CompuCall ICM CTI application will be replaced. New CTI applications must
operate over the current network infrastructure. If new CTI applications require a network
structure that is not compliant with the current data network, the Bidder must supplement
that network (components and equipment) and it must meet the security standards required
of the current data network.

                                                                                                Bidder
Requirement
                                           Requirement                              State Use   Agrees
Number
                                                                                                (Y/N)
   699        Requirement Deleted                                                                N/A
   700        Requirement Deleted                                                                N/A
   701        The System must have the ability to include an access control/audit   SUPP620
              log for all SCDB screen-pops, by agent, time, date, etc.



6C.5.21.8     Section Deleted
                                                                                                Bidder
Requirement
                                           Requirement                              State Use   Agrees
Number
                                                                                                (Y/N)
   702        Requirement Deleted                                                                N/A




1673D445-8846-415B-9B58-82958E8C824D.DOC                                            ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                 RFP OSI 7100-181
UIMOD PROJECT                                     SECTION 6C — PAGE 101 of 159



6C.5.21.9     Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                         State Use   Agrees
Number
                                                                                    (Y/N)
   703        Requirement Deleted                                                    N/A
   704        Requirement Deleted                                                    N/A



6C.5.21.10    Section Deleted
                                                                                    Bidder
Requirement                         Requirement                         State Use   Agrees
Number                                                                              (Y/N)
   705        Requirement Deleted                                                    N/A
   706        Requirement Deleted                                                    N/A



6C.5.21.11    Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                         State Use   Agrees
Number
                                                                                    (Y/N)
   707        Requirement Deleted                                                    N/A
   708        Requirement Deleted                                                    N/A
   709        Requirement Deleted                                                    N/A
   710        Requirement Deleted                                                    N/A
   711        Requirement Deleted                                                    N/A
   712        Requirement Deleted                                                    N/A



6C.5.21.12    Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                         State Use   Agrees
Number
                                                                                    (Y/N)
   713        Requirement Deleted                                                    N/A
   714        Requirement Deleted                                                    N/A




1673D445-8846-415B-9B58-82958E8C824D.DOC                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                 RFP OSI 7100-181
UIMOD PROJECT                                     SECTION 6C — PAGE 102 of 159



6C.5.22       Section Deleted

6C.5.22.1     Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                         State Use   Agrees
Number
                                                                                    (Y/N)
   715        Requirement Deleted                                                    N/A
   716        Requirement Deleted                                                    N/A



6C.5.22.2     Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                         State Use   Agrees
Number
                                                                                    (Y/N)
   717        Requirement Deleted                                                    N/A
   718        Requirement Deleted                                                    N/A



6C.5.22.3     Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                         State Use   Agrees
Number
                                                                                    (Y/N)
   719        Requirement Deleted                                                    N/A



6C.5.22.4     Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                         State Use   Agrees
Number
                                                                                    (Y/N)
   720        Requirement Deleted                                                    N/A
   721        Requirement Deleted                                                    N/A



6C.5.22.5     Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                         State Use   Agrees
Number
                                                                                    (Y/N)
   722        Requirement Deleted                                                    N/A




1673D445-8846-415B-9B58-82958E8C824D.DOC                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                 RFP OSI 7100-181
UIMOD PROJECT                                     SECTION 6C — PAGE 103 of 159



6C.5.22.6     Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                        State Use    Agrees
Number
                                                                                    (Y/N)
   723        Requirement Deleted                                                    N/A
   724        Requirement Deleted                                                    N/A



6C.5.22.7     Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                         State Use   Agrees
Number
                                                                                    (Y/N)
   725        Requirement Deleted                                                    N/A




1673D445-8846-415B-9B58-82958E8C824D.DOC                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                 RFP OSI 7100-181
UIMOD PROJECT                                     SECTION 6C — PAGE 104 of 159



6C.5.23       Section Deleted

6C.5.23.1     Section Deleted

6C.5.23.1.1 Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                         State Use   Agrees
Number
                                                                                    (Y/N)
   726        Requirement Deleted                                                    N/A



6C.5.23.1.2 Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                         State Use   Agrees
Number
                                                                                    (Y/N)
   727        Requirement Deleted                                                    N/A



6C.5.23.1.3 Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                         State Use   Agrees
Number
                                                                                    (Y/N)
   728        Requirement Deleted                                                    N/A



6C.5.23.1.4 Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                         State Use   Agrees
Number
                                                                                    (Y/N)
   729        Requirement Deleted                                                    N/A
   730        Requirement Deleted                                                    N/A



6C.5.23.1.5 Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                         State Use   Agrees
Number
                                                                                    (Y/N)
   731        Requirement Deleted                                                    N/A




1673D445-8846-415B-9B58-82958E8C824D.DOC                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                 RFP OSI 7100-181
UIMOD PROJECT                                     SECTION 6C — PAGE 105 of 159



6C.5.23.2     Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                         State Use   Agrees
Number
                                                                                    (Y/N)
   732        Requirement Deleted                                                    N/A
   733        Requirement Deleted                                                    N/A

6C.5.23.3     Section Deleted

6C.5.23.3.1 Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                         State Use   Agrees
Number
                                                                                    (Y/N)
   734        Requirement Deleted                                                    N/A
   735        Requirement Deleted                                                    N/A
   736        Requirement Deleted                                                    N/A
   737        Requirement Deleted                                                    N/A
   738        Requirement Deleted                                                    N/A
   739        Requirement Deleted                                                    N/A



6C.5.23.3.2 Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                         State Use   Agrees
Number
                                                                                    (Y/N)
   740        Requirement Deleted                                                    N/A
   741        Requirement Deleted                                                    N/A



6C.5.23.3.3 Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                         State Use   Agrees
Number
                                                                                    (Y/N)
   742        Requirement Deleted                                                    N/A



6C.5.23.3.4 Section Deleted
                                                                                    Bidder
Requirement
                                    Requirement                         State Use   Agrees
Number
                                                                                    (Y/N)
   743        Requirement Deleted                                                    N/A
   744        Requirement Deleted                                                    N/A
   745        Requirement Deleted                                                    N/A

1673D445-8846-415B-9B58-82958E8C824D.DOC                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                 RFP OSI 7100-181
UIMOD PROJECT                                     SECTION 6C — PAGE 106 of 159




6C.5.23.4       Section Deleted

6C.5.23.4.1 Section Deleted

6C.5.23.4.2 Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   746        Requirement Deleted                                                   N/A



6C.5.23.5       Section Deleted


6C.5.23.5.1 Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   747        Requirement Deleted                                                   N/A
   748        Requirement Deleted                                                   N/A
   749        Requirement Deleted                                                   N/A



6C.5.23.5.2 Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   750        Requirement Deleted                                                   N/A



6C.5.23.5.3 Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   751        Requirement Deleted                                                   N/A
   752        Requirement Deleted                                                   N/A



6C.5.23.5.4 Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   753        Requirement Deleted                                                   N/A

1673D445-8846-415B-9B58-82958E8C824D.DOC                                ADDENDUM 3          APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                 RFP OSI 7100-181
UIMOD PROJECT                                     SECTION 6C — PAGE 107 of 159




6C.5.23.5.5 Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   754        Requirement Deleted                                                   N/A



6C.5.23.5.6 Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   755        Requirement Deleted                                                   N/A



6C.5.23.6     Section Deleted
                                                                                   Bidder
Requirement                         Requirement                        State Use   Agrees
Number                                                                             (Y/N)
   756        Requirement Deleted                                                   N/A
   757        Requirement Deleted                                                   N/A



6C.5.23.7       Section Deleted

6C.5.23.7.1 Section Deleted
                                                                                   Bidder
Requirement
                                    Requirement                        State Use   Agrees
Number
                                                                                   (Y/N)
   758        Requirement Deleted                                                   N/A
   759        Requirement Deleted                                                   N/A
   760        Requirement Deleted                                                   N/A
   761        Requirement Deleted                                                   N/A




1673D445-8846-415B-9B58-82958E8C824D.DOC                                ADDENDUM 3          APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                    RFP OSI 7100-181
UIMOD PROJECT                                        SECTION 6C — PAGE 108 of 159



6C.5.24       Section Deleted

6C.5.24.1            Section Deleted
                                                                                       Bidder
Requirement
                                       Requirement                         State Use   Agrees
Number
                                                                                       (Y/N)
   762        Requirement Deleted                                                       N/A



6C.5.24.2            Section Deleted
                                                                                       Bidder
Requirement
                                       Requirement                         State Use   Agrees
Number
                                                                                       (Y/N)
   763        Requirement Deleted                                                       N/A
   764        Requirement Deleted                                                       N/A
   765        Requirement Deleted                                                       N/A



6C.5.24.3            Section Deleted
                                                                                       Bidder
Requirement
                                       Requirement                         State Use   Agrees
Number
                                                                                       (Y/N)
   766        Requirement Deleted                                                       N/A
   767        Requirement Deleted                                                       N/A
   768        Requirement Deleted                                                       N/A
   769        Requirement Deleted                                                       N/A
   770        Requirement Deleted                                                       N/A
   771        Requirement Deleted                                                       N/A
   772        Requirement Deleted                                                       N/A



6C.5.24.4            Section Deleted

6C.5.24.4.1 Section Deleted
                                                                                       Bidder
Requirement
                                       Requirement                         State Use   Agrees
Number
                                                                                       (Y/N)
   773        Requirement Deleted                                                       N/A
   774        Requirement Deleted                                                       N/A
   775        Requirement Deleted                                                       N/A




1673D445-8846-415B-9B58-82958E8C824D.DOC                                   ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                    RFP OSI 7100-181
UIMOD PROJECT                                        SECTION 6C — PAGE 109 of 159



6C.5.25       Architectural Considerations
Most of the requirements in this section were related to CCNPAU and have been
deleted. However, some information in this section has been retained to provide the
Bidder an understanding of the architecture adopted by CCNPAU. In addition, some
communication requirements in Section 6C.5.25.5, IVR System Architecture
Requirements – Communication, are applicable to the Web solution.


6C.5.25.1            Section Deleted
                                                                                       Bidder
Requirement
                                       Requirement                         State Use   Agrees
Number
                                                                                       (Y/N)
   776        Requirement Deleted                                                       N/A
   777        Requirement Deleted                                                       N/A
   778        Requirement Deleted                                                       N/A
   779        Requirement Deleted                                                       N/A
   780        Requirement Deleted                                                       N/A




1673D445-8846-415B-9B58-82958E8C824D.DOC                                   ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                                    RFP OSI 7100-181
UIMOD PROJECT                                                        SECTION 6C — PAGE 110 of 159



6C.5.25.2                  Conceptual Process Architecture

                   HTTP(S) URI


                                                      WS SOAP


                                                                                   WS SOAP




                                                                                 Data Entity

                                                Business Entity
                VoiceXML or CCXML
                     document



                                 Presentation Layer              Application Layer
 Speech Browser Platform         Web VXML/CCXML                 Business Services or           Data Access Layer
         Layer                    Document Server                Integration Broker



                      Figure 6C.3: Conceptual Process Architecture
Figure 6C.3 depicts the IVR Conceptual Process Architecture that has been adopted by
CCNPAU. In the adopted architecture, when a call is received, it is detected by the Speech
Browser platform. The platform sends an event to the CCXML or VoiceXML markup
interpreter, which looks in its context for the URI of the initial document to fetch. The
interpreter sends a Request to the Web VXML/CCXML Document Server for the initial
VXML/CCXML document. The Web VXML/CCXML Document Server sends the SOAP
request to the Business Service for the initial Business Entity. The Business Service sends
the SOAP request(s) to the Data Access Services for the initial Data Entities. The Data
Access Services sends Data Entities back to the Business Service. The Business Service
transforms Data Entities into Business Entity and sends the Business Entity back to the Web
VXML/CCXML Document Server.
The Web VXML/CCXML Document Server then uses Business Entity and meta-data
(VXML/CCXML templates) to dynamically build a VXML/CCXML document and sends the
VXML/CCXML document back to the CCXML or VoiceXML Markup Interpreter which
instructs the Speech Browser Implementation Platform on the first steps to perform on
behalf of the caller. The Markup Interpreter then interprets the result of an execution in the
Speech Browser Platform. The interpretation may result in the Markup Interpreter making
additional document requests to the Web VXML/CCXML Document Server.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                             ADDENDUM 3    APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 111 of 159



6C.5.25.3             Section Deleted


Figure 6C.4: Figure Deleted

6C.5.25.4             Section Deleted
                                                                                               Bidder
Requirement
                                           Requirement                             State Use   Agrees
Number
                                                                                               (Y/N)
   781        Requirement Deleted                                                               N/A
   782        Requirement Deleted                                                               N/A
   783        Requirement Deleted                                                               N/A
   784        Requirement Deleted                                                               N/A
   785        Requirement Deleted                                                               N/A
   786        Requirement Deleted                                                               N/A
   787        Requirement Deleted                                                               N/A
   788        Requirement Deleted                                                               N/A
   789        Requirement Deleted                                                               N/A
   790        Requirement Deleted                                                               N/A
   791        Requirement Deleted                                                               N/A
   792        Requirement Deleted                                                               N/A



6C.5.25.5             IVR System Architecture Requirements – Communication
                                                                                               Bidder
Requirement
                                           Requirement                             State Use   Agrees
Number
                                                                                               (Y/N)
   793        SOAP implementation must include multiple transports: HTTP, HTTPS    SUPP189
              and TCP.
   794        Transport selection must be done via configuration.                  SUPP190
   795        SOAP implementation must include configurable compression facility   SUPP191
              for SOAP Body, SOAP Header, and SOAP Direct Internet Message
              Encapsulation (DIME) attachments.
   796        Web Services must be SOAP 1.2 (or higher) compliant.                 SUPP192
   797        Requirement Deleted                                                               N/A




1673D445-8846-415B-9B58-82958E8C824D.DOC                                           ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                    RFP OSI 7100-181
UIMOD PROJECT                                        SECTION 6C — PAGE 112 of 159



6C.5.25.6            Section Deleted
                                                                                       Bidder
Requirement
                                       Requirement                         State Use   Agrees
Number
                                                                                       (Y/N)
   798        Requirement Deleted                                                       N/A
   799        Requirement Deleted                                                       N/A
   800        Requirement Deleted                                                       N/A
   801        Requirement Deleted                                                       N/A
   802        Requirement Deleted                                                       N/A
   803        Requirement Deleted                                                       N/A
   804        Requirement Deleted                                                       N/A
   805        Requirement Deleted                                                       N/A
   806        Requirement Deleted                                                       N/A
   807        Requirement Deleted                                                       N/A
   808        Requirement Deleted                                                       N/A
   809        Requirement Deleted                                                       N/A



6C.5.26       System Security Requirements

6C.5.26.1            Section Deleted
                                                                                       Bidder
Requirement
                                       Requirement                         State Use   Agrees
Number
                                                                                       (Y/N)
   810        Requirement Deleted                                                       N/A
   811        Requirement Deleted                                                       N/A
   812        Requirement Deleted                                                       N/A
   813        Requirement Deleted                                                       N/A
   814        Requirement Deleted                                                       N/A
   815        Requirement Deleted                                                       N/A
   816        Requirement Deleted                                                       N/A
   817        Requirement Deleted                                                       N/A
   818        Requirement Deleted                                                       N/A
   819        Requirement Deleted                                                       N/A
   820        Requirement Deleted                                                       N/A




1673D445-8846-415B-9B58-82958E8C824D.DOC                                   ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 113 of 159



6C.5.26.2             Section Deleted
                                                                                                 Bidder
Requirement
                                            Requirement                              State Use   Agrees
Number
                                                                                                 (Y/N)
   821        Requirement Deleted                                                                 N/A
   822        Requirement Deleted                                                                 N/A
   823        Requirement Deleted                                                                 N/A



6C.5.26.3             Section Deleted
                                                                                                 Bidder
Requirement
                                            Requirement                              State Use   Agrees
Number
                                                                                                 (Y/N)
   824        Requirement Deleted                                                                 N/A
   825        Requirement Deleted                                                                 N/A
   826        Requirement Deleted                                                                 N/A
   827        Requirement Deleted                                                                 N/A
   828        Requirement Deleted                                                                 N/A



6C.5.26.4             IVR Security Requirements
                                                                                                 Bidder
Requirement
                                            Requirement                              State Use   Agrees
Number
                                                                                                 (Y/N)
   829        Web Services (SOAP) implementation must be fully compliant with        SUPP194
              W3C Web-Security standard and include configurable support for
              Kerberos security token, X.509 Security token, Username security
              token, custom Security token, and SOAP Body/elements encryption.
   830        The Authentication service must be implemented as a Web Service        SUPP195
              and support multiple LDAP Directories with different schemas as
              Identity databases. Authentication services must use meta-data
              objects to define the mapping to any LDAP schema.
   831        The System must support Secure Socket Layer (SSL) and Transport        SUPP196
              Layer Security (TLS).
   832        Each Layer must perform Logging of security events and all service     SUPP197
              requests (Layer 1 and 2 have to support MS Windows Event Logging).
   833        Requirement Deleted                                                                 N/A
   834        The System must implement Single Sign-On (SSO) for callers and         SUPP199
              should not require callers to enter additional credentials to obtain
              services.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                             ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                      RFP OSI 7100-181
UIMOD PROJECT                                          SECTION 6C — PAGE 114 of 159



6C.6 CONTINUED CLAIMS REDESIGN REQUIREMENTS
The scope of the Continued Claims Redesign (CCR) sub project and the CCR System is
limited to UI except where discussed. The scope of the CCR System does not include initial
claims, adjudications or customer service (aside from supporting the ability of EPRs and
clients to inquire and update the status of continued claims and provide information
repositories). The scope of the CCR System includes continued claims processing,
operational reporting, fraud detection and web content publishing. The CCR System must
provide information repositories for Claimant demographics and eligibility information that
take account of initial claims requirements as defined by the Web Based Claim Filing
(WBCF) Project.
   1. The CCR System includes an on-line transaction processing system that supports
      payment related processes. The on-line transaction processing system will improve
      the quality and efficiency of payment related processes. (Payment related processes
      include continued claims submission and customer service transactions related to
      continued claims.)
   2. The CCR System includes customer self-service capabilities for continued claims
      entry and continued claims inquiries. The customer self-service capabilities will
      provide improved service to Claimants and improve the efficiency and quality of the
      continued claim process.
   3. The CCR System includes the provision of specific functionality for fraud prevention
      for payment related functions, which will improve the quality of the fraud prevention
      effort.
   4. The scope of audit and security logging is not limited and must include the capability
      to record all system and system access events.
   5. The CCR System includes a reporting capability that permits reporting across
      multiple information sources including demographic information, continued claims
      data, adjustment data, telephone call information, Web information (i.e., IP
      addresses), employee data, compromised SSNs and current investigation cases.
      This reporting capability will provide EDD with the opportunity to improve the quality
      and efficiency of the fraud prevention effort by identifying new patterns of fraud.
   6. The CCR System includes a reporting capability that enables managers to analyze
      and report transaction volume and key quality metrics. The reporting capability will
      provide EDD with the opportunity to further improve business processes by providing
      better information on process quality and transaction volumes.
   7. The CCR subproject includes the implementation of a tool that enables business
      subject matter experts to publish content to the EDD Web site without intervention by
      the EDD technical personnel. This effort includes an automated workflow process
      which will support an improved governance structure. The scope of Web content
      publishing is limited to the UI Branch of EDD.
   8. The intent of the CCR subproject is to automate existing processes. The CCR
      subproject does not include changing laws or regulations for UI processing.


1673D445-8846-415B-9B58-82958E8C824D.DOC                                        ADDENDUM 3     APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                        RFP OSI 7100-181
UIMOD PROJECT                                            SECTION 6C — PAGE 115 of 159



6C.6.1        Major System Conditions
The CCR System will be an n-tier Service Oriented Architecture (SOA) application using the
Microsoft .NET framework. The CCR System must also support major variants of the most
popular browser and user interfaces and should work in a similar fashion on any supported
browser. The CCR System must also meet any/all established EDD performance, security,
and operations requirements. Performance requirements include the need to provide 24x7
availability to customer self-service functions accessible via the Web or IVR. Security
requirements include the need to define screens and transactions to be logged and to be
able to store security logs to a secure location. Operations requirements include the need to
support multiple languages.


6C.6.1.1             Assumptions
    1. Some of the information captured in the initial claims process is stored in
        unstructured notes fields (e.g., special eligibility conditions). This prevents data
        validation and will impede processing by the CCR System.
     2. There are some known data quality issues with the historical data contained in the
        existing UI system.
     3. The EDD is undertaking the WBCF Project that will provide new infrastructure for
        some initial claims. The Initial Claims process establishes monetary eligibility as
        well as eligibility around the conditions of separation from the last employer. The
        process also collects information that formulates some eligibility requirements that
        must be met during the weekly certification process. An initial claim establishes a
        claimant‘s identity and collects demographic information used for authenticating
        identities and doing statistical analysis on the State‘s workforce. This Project will
        require additional repositories for eligibility and demographic information. The CCR
        System must provide these repositories as identified in the analysis conducted in
        conjunction with the WBCF effort.
         a)   The WBCF analysis ―deliverables‖ will be used to identify the information
              that must be stored. The CCR subproject will need to include these
              information requirements when data repositories for demographic and
              eligibility information are designed for the CCR System.
         b)   The CCR subproject will not have responsibility for creating an interface
              between the WBCF system and the CCR System.
         c)   The CCR subproject may leverage technical components created by the
              WBCF project, but is not required to do so.
     4. Claimants significantly depend on their unemployment payments. The EDD‘s IT
        infrastructure must be highly available and have good recovery capabilities. The
        implementation plan for the CCR System must provide for very strong parallel
        testing to ensure that systems are running effectively before they are used by
        Claimants.



1673D445-8846-415B-9B58-82958E8C824D.DOC                                           ADDENDUM 3   APRIL 8
  OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
  UIMOD PROJECT                                                   SECTION 6C — PAGE 116 of 159



        5. Printing to Office of Documents, Publication and Distribution (ODPD) of the
           Business Operations Planning and Support Division will require purchase of a
           postscript printing product. The EDD‘s preferred product is Extream Dialogue v5.
           Fifteen seat licenses will be required.
        6. The CCR System must be able to support EDD‘s standard desktop environment.

  6C.6.1.2               Dependent Projects
   Project or
                                Description                                Nature of Dependency
   Initiative
                  The ITARP Project is rolling out new       The CCR System will assume a level of desktop
IT Asset          infrastructure for supporting the          implementation, i.e., XP. The dependency relates
Replacement       desktop environment, and replacing         to potential issues if the affected desktops are not
Project (ITARP)   desktops with a new desktop of             replaced in the timeframes anticipated for the
                  standard configuration.                    UIMOD roll out.
                                                             The CCR subproject will create a new repository
                                                             for UI Claimant information. The information
                                                             collected by WBCF at initial claims needs to be
                  The WBCF Project will enhance the          considered in the CCR data model. Both Projects
                  application used by UI staff to file       deal with defining rules that establish and govern
Web-Based
                  initial claims and is expected to          eligibility for their respective functions, initial
Claim Filing
                  provide additional demographic             claims or continued claims. The CCR subproject‘s
(WBCF)
                  information and responses to eligibility   data modeling and business services need to
                  questions.                                 cover the full spectrum of eligibility. With the
                                                             presumption that WBCF will complete before
                                                             CCR, UIMOD will review WBCF analysis
                                                             documents for applicability to UIMOD.
                  The DIAP Phase III implements a
                  system to comply with security,
                  privacy and confidentiality provisions
                  of the Health Insurance Portability and    The Disability Insurance system shares the Single
Disability
                  Accountability Act (HIPAA).                Client Database and the PIN/IVR Database with
Insurance
                                                             UI. Modifications to shared components need to
Automation        The Project implements improved            avoid impact to the DI system. The
Project Phase     claim intake methods by offering           fraud/detection capabilities in the DI system need
III (DIAP3)       self-service options and automating        to be considered in the UI effort.
                  labor intensive manual processing.
                  The Project also implements fraud
                  detection and prevention capabilities




  1673D445-8846-415B-9B58-82958E8C824D.DOC                                                     ADDENDUM 3           APRIL 8
  OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
  UIMOD PROJECT                                                   SECTION 6C — PAGE 117 of 159



   Project or
                               Description                                 Nature of Dependency
   Initiative
                The EAO is responsible for the
                development, maintenance, and
                implementation oversight of the
                department‘s business, information,
                and technical architectures.
                                                             Potential Contractors will need to review, leverage,
Enterprise      The EAO is undertaking several               and comply with these architectures and their
Architecture    architecture definition efforts including:   related product selections, infrastructures, and
Projects        Applications / SOA, Identity                 processes. See Bidders‘ Library, EDD Enterprise
(various)       Management / Privacy, Security / Risk        Architecture Reference Model/Supporting
                Management, Network /                        Documents Folder.
                Telecommunications, Business
                Intelligence, and Enterprise Business
                Architecture including the identification
                of enterprise level services, e.g., file
                claim, determine eligibility.
Unemployment    The UISS Legacy Renewal Project will
Insurance       leverage AllFusion Gen model-based
                                                             The CCR System will need to interface with the
Scheduling      development tools to convert the
                                                             UISS to schedule and cancel appointments, as
System (UISS)   COBOL-based legacy UISS
                                                             well as to provide information to claimants
Legacy          application to a .NET web service and
                                                             regarding their scheduled appointments.
Renewal         incorporate functionality currently
Project         provided by macros.




  1673D445-8846-415B-9B58-82958E8C824D.DOC                                                    ADDENDUM 3            APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                    RFP OSI 7100-181
UIMOD PROJECT                                        SECTION 6C — PAGE 118 of 159



6C.6.2       Operational Scenarios
The following are descriptive examples of how the CCR System will be used (in
chronological order) through a given week:
 1. The CCR System will be available for Public Customers to manage claimant
    accounts via the Web or IVR on a 24 x 7 basis.
 2. During times when one or more external systems are not available, the CCR
    System will retain data and will upload or synchronize with these systems when
    they become available.
 3. At 6:30 a.m. on each weekday morning, the CCR System will be available for
    EPRs, Managers, Operations Managers or Program Analysts and System Account
    Administrators. It will remain in this mode through 6:00 p.m. each day. Interfaces
    to other internal systems will generally operate in ―real-time‖ during these hours.
 4. The CCR System for internal users will generally not be required to be available on
    Saturdays, but on some Saturdays the system will need to be made available all
    day for staff (to relieve work backlog).
 5. During periods of unavailability, a message will transmit stating unavailability and
    hours of availability. These periods will be used for system maintenance and
    upgrades.
 6. On State holidays that do not occur on Saturdays, the system will operate on a
    weekend schedule.
 7. The EDD requires the capability to adjust operational schedules (operating hours,
    etc.) without assistance of a third party Contractor.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                        ADDENDUM 3   APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                          RFP OSI 7100-181
UIMOD PROJECT                                              SECTION 6C — PAGE 119 of 159



6C.6.3        System Performance Characteristics
The Contractor must build the CCR System to accommodate the capacity, availability and
response-time requirements specified in this section.
At this time the EDD will allow Claimants to choose the method for each certification and
generally not restrict access to any certification channel as part of the CCR System (other
States restrict Claimants to a specific certification day and/or time – known as ―Load
Balancing‖). This does not conflict with EDD‘s need to restrict individual Claimants or
groups of Claimants from certain certification channels based on the eligibility rules
applicable to that particular Claimant or group.
Therefore, certification transaction volumes are stated without specifying a channel. Each
channel must be able to accommodate the maximum peak hourly UI certification workload.
However, the maximum hourly peak will not occur during the initial production configuration
and the lower system capacity figure allows for collection of certification volumes and
planning for scaling.
Other States experience 60-100 percent telephonic and 10-25 percent Web certification
utilization rates. Only one State has eliminated paper certification forms completely. (The
EDD does not plan on eliminating paper certification.) Initially, Web certifications will most
likely mirror the current eApply4UI application‘s utilization rates (≈30 percent). However,
EDD expects that most claimants will use the telephonic channel for certification.
Overall, it is estimated once all releases of the CCR subproject are deployed, 78 percent of
all claimants will certify for UI benefits using electronic methods, with the prospect (with
sufficient marketing and Claimant acceptance) that eventually only 10 percent of all
continued claims will be processed on paper.

6C.6.3.1             System Capacity Requirements
                                                                                                 Bidder
Requirement
                                         Requirement                                State Use    Agrees
Number
                                                                                                 (Y/N)
   835        The Contractor must demonstrate that system performance               SUPP336
              requirements are met when the amount of UI data in the CCR System
              matches that of the SCDB system at the time of the performance
              tests.
   836        The Contractor must build the System so that the initial production   SUPP340
              configuration can accommodate 20,000 continued claim certifications
              per hour.
   837        The Contractor must certify that the CCR System can scale to          SUPP341
              accommodate 40,000 continued claims certifications per hour.
   838        The initial production configuration must be able to accommodate      SUPP342
              3,800 EDD (internal) users. This is the total number of EDD
              employees that must be able to log into and access the CCR System
              via the internal network.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                            ADDENDUM 3            APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 120 of 159


                                                                                                     Bidder
Requirement
                                           Requirement                                   State Use   Agrees
Number
                                                                                                     (Y/N)
   839        The initial production configuration must be able to accommodate 1.2       SUPP343
              million Web users (total, not concurrent). This is the total number of
              Public Customers that must be able to log into and access the CCR
              System via the Web.
   840        The initial production configuration must be able to accommodate 1.2       SUPP344
              million external users accessing the CCR System using the IVR
              system. This is the total number of Public Customers that must be
              able to log into and access the CCR System using the IVR system.
              These users will be using the CCR Enterprise Services via the IVR.
   841        The initial production configuration must be able to accommodate           SUPP345
              6,700 concurrent users. This is the total number of users of all types
              that must be able to submit transactions concurrently. This number is
              derived from the peak continued claims per hour, the assumption that
              each user is doing 1.5 continued claims per session, and the
              assumption that each user spends 30 minutes per session.
   842        The Contractor must certify that the CCR System can scale to               SUPP346
              accommodate 13,400 concurrent users. This is the total number of
              users of all types that must be able to submit transactions
              concurrently. This number is derived from the maximum peak
              continued claims per hour, the assumption that each user is doing 1.5
              continued claims per session, and the assumption that each user
              spends 30 minutes per session.
   843        The initial production configuration must be able to process 29 million    SUPP347
              continued claims annually while meeting all other performance
              requirements.
   844        The initial production configuration must be able to process 3.5 million   SUPP348
              demographic updates annually.
   845        The initial production configuration must be able to process 18 million    SUPP349
              UI payments annually.
   846        The initial production configuration must be able to process 4.4 million   SUPP350
              customer service inquiries annually.
   847        The initial production configuration must be able to accommodate 1.8       SUPP351
              million customer self-service inquiries annually.
   848        The initial production must have sufficient storage capacity to            SUPP352
              accommodate four million active claims.
   849        The initial production configuration must have sufficient storage          SUPP353
              capacity to accommodate 140 million UI payments.
   850        The initial production configuration must have sufficient storage          SUPP354
              capacity to accommodate 210 million continued claims.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                 ADDENDUM 3           APRIL 8
   OFFICE OF SYSTEMS INTEGRATION                                                 RFP OSI 7100-181
   UIMOD PROJECT                                                     SECTION 6C — PAGE 121 of 159



   6C.6.4            Adaptability and Extensibility
   The EDD estimates that the peak filing of claim-weeks will be 35,000 continued claims per
   hour. This is based on an analysis of fifteen years of continued claims data, and also based
   on other States experience with Web filing and IVR systems (the max workload is focused
   on Sunday and Monday in a nonlinear distribution of load).
   The existing Single Client Database (SCDB) system averages approximately 145 gigabytes
   (GB), which includes Disability Insurance, but also includes the monthly archiving of
   Claimant data that has not been accessed within a certain period of time. The EDD
   estimates UI claim data initial storage requirement as 200GB. This was estimated by taking
   100GB, and multiplying a factor of two (2) for the additional data needs and expansion of the
   CCR System.

   However, customer demands on the UI program are volatile. As the economy fluctuates the
   Unemployment rate and those filing for benefits can double. As the California population
   increases, so do the number of persons requesting benefits. As employment moves toward
   more service related jobs, the periods of unemployment increase. All of these factors can
   be expected to increase the needed capacity of the CCR System.
   The tables below illustrate California‘s population, its expected growth over the next thirty
   years and how the workload can fluctuate depending on economic conditions.

   Table 6C.3 California Population Data and Projections from US Census Bureau
                                                           2010 Census      2020 Census      2030 Census
                California                2000 Census       Projection       Projection       Projection
          Total Population          33,871,648       38,067,134          42,206,743         46,444,861


   Table 6C.4 California Workforce and Unemployment Rates
                                    Civilian Labor                                          Unemployment
    State Fiscal Year (SFY)                             Employment       Unemployment
                                        Force                                                   Rate
             2001-02                 17,246,000         16,161,000         1,085,000         6.3 percent
             2002-03                 17,384,000         16,169,000         1,188,000         6.8 percent
             2003-04                 17,455,000         16,301,000         1,154,000         6.6 percent
             2004-05                 17,659,000         16,642,000         1,017,000         5.8 percent


   Table 6C.5 California UI Continued Claims Workload and Performance
                                             Weeks
              Weeks             OCR                         Unemployment          FPTL          CCPTL
 SFY                                      Processed by
              Claimed        Exceptions                         Rate           Percentage     Percentage
                                          CUISC EPRs
2001-02     26,951,160       15,399,893     7,896,690             6.3%           85.04%         83.23%
2002-03     27,748,806       15,855,668     8,130,400             6.8%           83.73%         83.20%
2003-04     24,464,173       13,978,828     7,168,003             6.6%           82.32%         83.60%
2004-05     19,755,841       11,288,488     5,788,461             5.8%           82.23%         82.71%

   1673D445-8846-415B-9B58-82958E8C824D.DOC                                                 ADDENDUM 3     APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 122 of 159



The number of Internal EDD users is calculated by the number of workstations in the UI field
offices, UI Division and Branch offices and estimated staff numbers from the Program
Review, Auditing and Evaluations, Quality Control and Investigations offices.
The number of external EDD users is derived from initial claims data. The EDD files
approximately 3.5 million initial claims per year. Since roughly 30 percent of claimants who
filed initial claims, never actually file continued claims and the maximum benefits are
collected for only 26 weeks, the active Claimant pool available to access the system at any
one time is estimated to be 1.2 million users. However, Bidders will need to take California‘s
expected population growth into account when designing their proposed solution.
As a result, EDD needs a system that is scalable, beyond the initial capacity, to meet
additional capacity requirements of the UI program and additional program functionality that
may be added to the system.

6C.6.4.1              Adaptability and Extensibility Requirements
                                                                                                    Bidder
Requirement
                                            Requirement                                 State Use   Agrees
Number
                                                                                                    (Y/N)
   851        The CCR System must scale through the addition of hardware                SUPP337
              capacity (e.g., servers/network bandwidth), and not require that the
              software solution be re-designed or modified in order to add additional
              capacity.
   852        Requirement Deleted                                                                    N/A
   853        All servers in initial production configuration must be expandable with   SUPP339
              respect to CPUs and memory. They must be sized to run at 50% of
              the estimated capacity needs in the initial production configuration.
   854        The System must allow for taking any individual component of the          SUPP851
              CCR System off-line, performing an upgrade or other system
              maintenance activity, and placing that component back into production
              operation, without requiring any system downtime during the entire
              process.



6C.6.4.2              System Availability Requirements
                                                                                                    Bidder
Requirement
                                            Requirement                                 State Use   Agrees
Number
                                                                                                    (Y/N)
   855        The initial production configuration must enable EDD internal users to    SUPP355
              access the System from 6:30am to 6pm, Monday to Friday (Saturday
              on request).
   856        With the exception of scheduled downtime for periodic maintenance,        SUPP356
              the initial production configuration must support accessibility by Web
              and IVR users 24 hours a day, seven (7) days a week.
   857        Mandatory/Optional                                                        SUPP357
              The availability of the end user reporting environment must be the
              same as the on-line transaction processing environment.



1673D445-8846-415B-9B58-82958E8C824D.DOC                                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 123 of 159



In addition to providing acceptable response time to EDD customers (Web users), the CCR
System must have response times for the EPRs (intranet and ―rich client‖ users) that is
comparable to the sub-second response time experienced with the 3270 mainframe
applications.

6C.6.4.3             System Response Time Requirements
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   858        The initial production configuration for Web clients accessing the        SUPP358
              System over the Web (using a network connection that offers a speed
              approximately equal to 128kb up and 256kb down) must provide end-
              to-end response time that meets the following guidelines: 80 percent
              of the forms must respond in less than four (4) seconds; 90 percent of
              the forms must respond in less than six (6) seconds; 98 percent of the
              forms must respond in less than 10 seconds; End to end response
              time is defined as the time from which the page or form is submitted,
              to the time that the last byte has been received by the browser.
   859        The initial production configuration for Web clients accessing the        SUPP359
              System over the intranet (using a network connection that offers a
              speed approximately equal to 1.5mbps up and down - T1 speed)
              must provide end-to-end response time that meets the following
              guidelines: 90 percent of the forms must respond in less than three
              (3) seconds; 98 percent of the forms must respond in less than four
              (4) seconds. End to end response time is defined as the time from
              which the page or form is submitted, to the time that the last byte has
              been received by the browser.
   860        The initial production configuration for smart clients accessing the      SUPP360
              System over the intranet (using a network connection that offers a
              speed approximately equal to 1.5Mbps up and down - T1 speed)
              must provide end-to-end response time that meets the following
              guidelines: 90 percent of the forms must respond in less than two (2)
              seconds; 98 percent of the forms must respond in less than three (3)
              seconds. End to end response time is defined as the time from which
              the page or form is submitted, to the time that the last byte has been
              received by the browser.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 124 of 159



6C.6.5         System Security
The Contractor must build the CCR System to accommodate the security requirements
specified in the following sections.

6C.6.5.1              General Security Requirements
                                                                                                  Bidder
Requirement
                                           Requirement                                State Use   Agrees
Number
                                                                                                  (Y/N)
   861        The CCR System must comply with International Standards                 SUPP361
              Organization 17799 Security standard.
   862        The CCR System services for identification and authentication of        SUPP362
              Claimants must be accessible by external systems (e.g., the WBCF
              system) built using the .NET Framework (or a later comparable
              application development framework from Microsoft).
   863        The CCR System must comply with Federal Information Security            SUPP549
              Management Act (FISMA) OMB A130 Appendix III security
              requirements.
   864        The CCR System must comply with State Information Security              SUPP551
              Policies, as prescribed in the State Administrative Manual, Sections
              4841 through 4845, the EDD Information Security Policy, contained in
              the Bidders‘ Library, and the DTS Information Technology Security
              Policy (See Bidders‘ Library, Security Standards folder).
              The System must use EDD's Oracle Identity Management Solution as        SUPP867
   864A       the platform for all Identity Management functions, including
              authentication, authorization, and identity provisioning.



6C.6.5.2              Self-Registration Requirements
The CCR System must allow claimants the ability to register with no CSR intervention
required. The section below describes the requirements for self-registration on both the IVR
and the web.

                                                                                                  Bidder
Requirement
                                           Requirement                                State Use   Agrees
Number
                                                                                                  (Y/N)
   865        The CCR System, inclusive of the end user reporting environment ,       SUPP363
              must provide administration tools that support security control for
              authentication and access management.
   866        The CCR System must provide an authoritative source of identity data    SUPP364
              to provision Web users via self-registration.
   867        To facilitate identity management the CCR System must support           SUPP366
              Single Sign-On and dynamic provisioning via self-service.
   868        The CCR System must provide a self-service facility for Web users for   SUPP367
              identity management.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                              ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 125 of 159


                                                                                                      Bidder
Requirement
                                            Requirement                                   State Use   Agrees
Number
                                                                                                      (Y/N)
   869        Intranet users must use Integrated Windows Authentication for smart         SUPP368
              client and browser.
   870        Incoming Request Adapters (used for external interfaces) must be            SUPP369
              responsible for authenticating the caller before allowing access to the
              CCR System.
   871        The CCR System must provide a self-registration facility for claimants      SUPP760
              via the Web and IVR.
   872        The self-registration facility must use Web Service interface to support    SUPP761
              external source verification (direct Web Service call or via External
              Interface Gateway).
   873        The self-registration facility must support configuring authentication      SUPP762
              factors to be specific to the different types of EDD end-users.
   874        Requirement Deleted                                                                      N/A
   875        The self-registration facility must protect itself from registration by     SUPP764
              software ―robots‖ or automated processes. This could be accomplished
              by utilizing a factor that prevents the application software from
              completing the registration without human intervention (e.g., Web user
              must re-type image displayed on screen that is only recognized by
              human eye.).
   876        A self-registration facility must assign a new user a unique global         SUPP765
              identifier, which can be used for further identification.
   877        A self-registration facility must assign a new user a unique PIN for IVR    SUPP766
              and complex password for Web access, which can be used for further
              authentication of the user.
   878        Requirement Deleted                                                                      N/A
   879        The self-registration facility must record the user IP address and other    SUPP768
              characteristics of the PC used for registration, and use this information
              as one of the factors for authentication.
   880        The self-registration facility must provide strong authentication which     SUPP845
              includes multiple factors. ―Strong authentication‖ must have multiple,
              configurable factors, verified against external validation sources.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                  ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 126 of 159



6C.6.5.3               Identity Provider Requirements
The Security infrastructure will include functionality that will authenticate the identity of a user
with a configurable number of factors. This centralized sub-system will act as a single point
of authentication for the UIMOD applications.

                                                                                                       Bidder
Requirement
                                             Requirement                                   State Use   Agrees
Number
                                                                                                       (Y/N)
   881        The Identity Provider facility must provide configurable event               SUPP378
              notification functions to notify the CCR System application and user
              about login, password changes and resets that occur in the Identity
              Provider.
   882        The System must use an Identity Provider facility for self-registration,     SUPP769
              identity management and authentication.
   883        Requirement Deleted                                                                       N/A
   884        Requirement Deleted                                                                       N/A
   885        Requirement Deleted                                                                       N/A
   886        Requirement Deleted                                                                       N/A
   887        Requirement Deleted                                                                       N/A
   888        The Identity Provider facility must support synchronization of users         SUPP775
              profiles in application database(s) with user profile in Active Directory
              (e.g. if a user is disabled in one AD, the user is also disabled in the
              ―linked‖ AD).
   889        The Identity Provider facility must use Security Policy to control           SUPP776
              credentials, authentication, and registration.
   890        The Identity Provider facility must support clustering for load balancing    SUPP777
              and high availability of Identity management services.
   891        The Identity Provider facility must generate during sign-in a session        SUPP778
              token shared by all registered Web Applications and/or Web Services
              for requests authentication and single sign-on.
   892        CCR Web applications must use a session cookie as container for              SUPP779
              session token generated by the Identity Provider facility and must
              validate/authenticate a session token for each request.
   893        CCR Web Services must use SOAP Header as the container for                   SUPP780
              session token generated by The Identity Provider facility and must
              validate/authenticate the session token for each request.
   894        The Identity Provider facility must support the use of different, multiple   SUPP781
              Directory Services concurrently for authentication of different
              categories of users, which share the same Web Services and
              application databases (e.g. intranet users, web users and extranet
              users).
   895        The Identity Provider facility must support configurable                     SUPP782
              challenge/response questions and answers. Administrator must be
              able to define actual challenge questions.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                   ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 127 of 159


                                                                                                     Bidder
Requirement
                                             Requirement                                 State Use   Agrees
Number
                                                                                                     (Y/N)
   896        The Identity Provider facility must allow a self-registration user the     SUPP783
              ability to define a configurable number of personalized challenge
              questions and responses.
   897        The Identity Provider facility must support allowing an administrator to   SUPP784
              choose the number of administrator-defined questions and user-
              defined questions needed for authentication.
   898        The Identity Provider facility must be able to verify, during sign-in,     SUPP785
              answers to challenge questions against Web Services results
              retrieved from application database.
   899        The Identity Provider facility must be able to use challenge/response      SUPP786
              questions during any sign-in from Web browser or IVR.
   900        The Identity Provider facility must support mechanisms to help the         SUPP787
              user "authenticate" the system (e.g. provide a user-selectable unique
              personal image tag or word assigned to a server).
   901        The System must include an Identity Provider facility that will provide    SUPP858
              authentication and authorization services for all UIMOD system users.
   902        Requirement Deleted                                                                     N/A
   903        The Identity Provider facility must support mechanisms to prevent          SUPP860
              software robots logins and registrations.
   904        Requirement Deleted                                                                     N/A



6C.6.5.4               Authentication Requirements
                                                                                                     Bidder
Requirement
                                             Requirement                                 State Use   Agrees
Number
                                                                                                     (Y/N)
   905        An authentication facility must provide automatic authentication status    SUPP788
              feedback to the user (e.g. auto requests user to reenter information,
              after certain number of tries may escalate to an agent workflow queue,
              may send claimant multiple notifications—e-mail, US mail).
   906        The authentication facility must have a configurable option to send        SUPP789
              notifications to the user for administrator-defined security events.
   907        The Authentication facility must include the capability for:               SUPP790
              a) Multi-factor authentication (Use minimum of 2 factors, main factor
              user name and password, second factor computer address, ANI, etc.
              When necessary can request responses to challenge/response
              questions and answers.
              b) Use of a one-time temporary factor (e.g. the System generates
              temporary PIN that the claimant must use for next session).
   908        The Authentication facility must enforce use of TLS/SSL for entire web     SUPP791
              session and deny service for non-SSL/TLS requests.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                 ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 128 of 159


                                                                                                       Bidder
Requirement
                                             Requirement                                   State Use   Agrees
Number
                                                                                                       (Y/N)
   909        The Authentication facility must be secured from attempts to steal or        SUPP792
              impersonate the session cookie. (A recommended solution will enforce
              session cookie construction policy for session token and use industrial
              strength encryption/hashing and use client PC partial IP address).
   910        The Authentication facility must protect itself from sign-in requests by     SUPP793
              software robots.
   911        Web Applications must have security protection against attacks               SUPP794
              designed to steal session (e.g., cross-site scripting).
   912        The Authentication facility must protect user from Phishing attacks          SUPP795
              (e.g., Registration process forces personalization of each user‘s
              presentation of CCR web interface and sign-in uses personalized Web
              Site identification/image).
   913        The CCR System must use the Identity Provider facility for sign-in           SUPP796
              authentication and must not rely on a Web Access Proxy system for
              sign-in authentication.
   914        The Authentication facility must support the ability for the user to sign-   SUPP797
              in (using other authentication factors) and reset their password to a
              temporary password in the case that they have forgotten their
              password.



6C.6.5.5               Authorization Requirements
                                                                                                       Bidder
Requirement
                                             Requirement                                   State Use   Agrees
Number
                                                                                                       (Y/N)
   915        Authorization must use a role-based access control model.                    SUPP385
   916        Authorization must be implemented via Code Access Security using             SUPP386
              strong names and Call Path Policies.
   917        Authorization must be implemented via Database Stored Business               SUPP387
              Entities objects Access Security.
   918        Authorization must be implemented via Web Forms/Windows Controls             SUPP388
              Access Security.
   919        Authorization must be implemented via Web Services Access                    SUPP389
              Security.
   920        Authorization must be implemented via Enterprise Service Access              SUPP390
              Security.
   921        All authorization controlled at the access control layers must be            SUPP391
              implemented with externalized security policies (grants and rules).
   922        The Authorization facility must control access to logical resources          SUPP396
              (Application Services/Transactions and Business Objects) for all
              system users (e.g. Intranet, Web, IVR).
   923        The Business Façade must analyze all service requests to determine if        SUPP397
              the client has the ―right to execute‖ the specified request.


1673D445-8846-415B-9B58-82958E8C824D.DOC                                                   ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 129 of 159




6C.6.5.6              Distributed Security Infrastructure Threat Protection Requirements
                                                                                                     Bidder
Requirement
                                            Requirement                                  State Use   Agrees
Number
                                                                                                     (Y/N)
   924        The security infrastructure must implement application and state           SUPP398
              integrity, system integrity, data integrity, service and message content
              and protocol validation.
   925        The Data Validation rules for Business Entities must be configurable.      SUPP399
   926        The CCR System must provide an administration tool to allow data           SUPP400
              validation rules to be configured and stored in a repository.
   927        All Security Infrastructure protection layers must be isolated from        SUPP401
              application layers and components in such way that compromised
              application components may not bypass or compromise security
              infrastructure protection layers or other application layers.
   928        Web Service input content and protocol validation must use XML             SUPP402
              Schema Definition (XSD) and security/business policy rules for
              preventing buffer overflow and malicious content from compromising
              applications or application states.
   929        Web Service response content and protocol validation must use XSD          SUPP403
              and security/business policy rules for preventing buffer overflow and
              malicious content from compromising applications or application
              states.
   930        Message Queuing request/response message content and protocol              SUPP404
              validation must use XSD and security/business policy rules for
              preventing buffer overflow and malicious content from compromising
              applications or application states.



6C.6.5.7              SOA Security Requirements
                                                                                                     Bidder
Requirement
                                            Requirement                                  State Use   Agrees
Number
                                                                                                     (Y/N)
   931        The CCR System must support mechanisms that allow service                  SUPP631
              providers to determine if service requestors are authorized to use the
              requested resource.
   932        The CCR System must be able to verify that message data has not            SUPP633
              been changed or damaged in transit, either through accidental or
              nefarious means.
   933        Message data may be persisted in one or more places during the             SUPP634
              course of a web services interaction. The CCR System must ensure
              full fidelity and integrity of data as it is stored and retrieved or
              serialized and de-serialized.
   934        The CCR System must be able to ensure that unauthorized entities           SUPP635
              cannot view or access sensitive information (all or part of a message)
              while it is in transit.


1673D445-8846-415B-9B58-82958E8C824D.DOC                                                 ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 130 of 159


                                                                                                      Bidder
Requirement
                                             Requirement                                  State Use   Agrees
Number
                                                                                                      (Y/N)
   935        The CCR System must be able to ensure that unauthorized entities            SUPP636
              cannot view or access sensitive information (all or part of a message)
              while it is in memory or persisted.
   936        The CCR System must be able to detect duplicate messages, which             SUPP637
              may be used in replay and DoS attacks.
   937        The CCR System must be able to validate messages and message                SUPP638
              attachments to ensure that they contain appropriate data and do not
              contain attack vectors, such as viruses and worms, or compromising
              message content, such as SQL injections.
   938        The CCR System must support the ability to audit all web service            SUPP639
              interactions.
   939        The CCR System should support monitoring of web services                    SUPP640
              interactions to enable detection of potential security breaches and
              fraud, and to generate configurable notifications to security
              administrators.
   940        The web services security infrastructure should integrate with existing     SUPP641
              public key infrastructure (PKI) and Identity Management (IdM)
              systems.
   941        The CCR System must support the ability to establish and recognize          SUPP642
              trust relationships and to map credentials from one trust domain to
              another.
   942        The CCR System must allow each distinct business domain to                  SUPP643
              configure its own security policies and participate in a workflow
              process to negotiate security policies with its internal and external
              partners.



6C.6.5.8               System Requirements for Protection of Confidential Information
                                                                                                      Bidder
Requirement
                                             Requirement                                  State Use   Agrees
Number
                                                                                                      (Y/N)
   943        Confidential information must be secured by ensuring identification         SUPP405
              and authentication, audit trails, and system access parameters to limit
              access only to the information required by the requester's business
              functions, and authorized by law.
   944        All systems must include audit trail facilities to permit recording every   SUPP406
              access to confidential and sensitive information.
   945        The CCR System must use a unique UI Identifier for each Claimant as         SUPP407
              a primary identifier for account access instead of SSN.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                  ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 131 of 159


                                                                                                        Bidder
Requirement
                                             Requirement                                    State Use   Agrees
Number
                                                                                                        (Y/N)
   946        The SSN and other confidential information must be stored in Session          SUPP408
              States of Web Applications, in Session States of Smart Client
              applications and in Database as a confidential attribute in encrypted
              form using AES or stronger current Federal encryption standards, and
              must use SHA256 or SHA512 hashing for confidential data, which
              should not be decrypted.
              The same confidential attributes (SSN, etc) must be transmitted in
              SOAP messages only in encrypted form using AES or stronger current
              Federal encryption standards, and must use SHA256 or SHA512
              hashing for confidential data, which should not be decrypted
              (additionally to the use of SSL/TLS).
              Object Schemas must allow an authorized administrator to specify
              confidential attributes/elements and protection method (encryption,
              hashing). It also must allow one to specify a short suffix of confidential
              attribute to be stored as clear text (for example, the last four (4) digits
              of the SSN).
   947        The Contractor must allow the choice of encryption algorithm to be            SUPP409
              configurable by EDD to adapt to changing technologies.
   948        Confidential information that is encrypted or hashed must retain an           SUPP410
              attribute that specifies the SALT, Key ID, hashing, or encryption
              algorithm used. This will allow the application to dynamically apply the
              correct algorithm even when multiple algorithms may have been used.



6C.6.5.9               Secure Connectivity Requirements
                                                                                                        Bidder
Requirement
                                             Requirement                                    State Use   Agrees
Number
                                                                                                        (Y/N)
   949        All communications between the Web server(s) in the DMZ and the               SUPP411
              user‘s Web browser must be encrypted using SSL.
   950        The CCR System must protect the privacy and integrity and                     SUPP412
              confidentiality of all confidential and sensitive information (including
              passwords, SSN) being sent across the Web.
   951        All communications between the Web servers in the DMZ and internal            SUPP413
              application servers must be protected using WS-Security with
              Kerberos tokens and XML encryption.
   952        The CCR System must protect the privacy and integrity of all                  SUPP414
              confidential and sensitive information being sent within the EDD
              network.
   953        All communications between the Web servers and internal users must            SUPP415
              be protected by SSL.
   954        Client to Service communication must use XML encryption for                   SUPP417
              confidential data based on Kerberos tokens.
   955        The CCR System must conform to all Federal and State regulations              SUPP418
              for display of SSN.


1673D445-8846-415B-9B58-82958E8C824D.DOC                                                    ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                          RFP OSI 7100-181
UIMOD PROJECT                                              SECTION 6C — PAGE 132 of 159


                                                                                              Bidder
Requirement
                                          Requirement                             State Use   Agrees
Number
                                                                                              (Y/N)
   955A       Clear text passwords or keys must be sent via SSL or encrypted by   SUPP416
              Kerberos tokens.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                          ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                                 RFP OSI 7100-181
UIMOD PROJECT                                                     SECTION 6C — PAGE 133 of 159




6C.6.6         Audit Logging
The audit logs will be used both for security needs as well as by application developers.
The security-related log entries must be accessible for read-only operation and available to
users with appropriate access privileges.
The CCR System must include the following security logging and audit facilities:
     1. Data Audit: the facility to log and audit all data entities changes and meta-data
        changes.
     2. Activity Audit: the facility to log and audit all operations, service requests,
        interactions, messages.
     3. Security events audit: the facility to log and audit all security events.

6C.6.6.1               System Data Audit Logging Requirements
                                                                                                        Bidder
Requirement
                                              Requirement                                   State Use   Agrees
Number
                                                                                                        (Y/N)
   956        All changes or updates to data must be time and date stamped.                 SUPP599
   957        The CCR System data audit component must provide data audit                   SUPP798
              functionality for all CCR System data and meta-data.
   958        The CCR System must not allow security administrator, database                SUPP799
              administrator, system administrator or any user to turn off Data Audit
              or change its settings.
   959        The CCR System data audit component must, during Update and                   SUPP800
              Delete transactions, store a complete, distinct, older version of the
              changed/deleted data entity.(A Data Entity is a Business Entity Object
              stored in a relational database as a set of related records. Each data
              entity has a unique primary key.)
   960        All old versions of any data entity in the CCR database must have a           SUPP801
              relationship to the current version of a data entity in order to facilitate
              reporting.
   961        All versions of any data entity must have the same attributes                 SUPP802
              selectable by SQL as a current data entity version.
   962        Updates and Data Audit records insertion must not change Primary              SUPP803
              Key of the current version of a data entity.
   963        The CCR database must support queries that return result sets                 SUPP804
              showing the requested data object state as it was at the specified
              effective date.
   964        The CCR System data access and data audit components must                     SUPP805
              provide functions to return all versions for any data.
   965        The CCR System data access and data audit components must                     SUPP806
              provide access to data entity versions to clients based on their
              authorization capabilities. (For example, clients with read/write
              capabilities to a data entity must have read capabilities on versions of
              that data entity. Clients with no access to a data entity must have no
              access to the versions for that data entity).

1673D445-8846-415B-9B58-82958E8C824D.DOC                                                    ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 134 of 159


                                                                                                   Bidder
Requirement
                                           Requirement                                 State Use   Agrees
Number
                                                                                                   (Y/N)
   966        The CCR System data entity Update and Delete transactions must be        SUPP807
              rolled back when the Data Audit component can not create an old
              version of a data entity with all required attributes populated.
   967        The CCR System data audit records insert/updates must roll back          SUPP808
              when an audited data entity update/delete transaction is rolled back.
   968        Data Audit and Data Access components must not allow a change to         SUPP810
              the state of old versions of data entities.
   969        The CCR Data Access layer must not allow database administrators or      SUPP811
              security administrator to bypass the data audit component and the
              data access layer and make direct changes in the CCR database
              using any SQL Server tool or application (i.e. MS Enterprise Manager,
              etc). (To implement this, the data audit component can calculate and
              encrypt every data entity state as a hash and store the hash as an
              attribute with every version of each data entity. Additionally the CCR
              data access layer must not allow the application to work with data
              entities (record sets), which do not have valid encrypted hash.
   970        The data audit component must include a report to return all database    SUPP812
              records that have been modified by bypassing the data access layer.
   971        The data audit component must not decrypt confidential encrypted         SUPP813
              attributes of data entities when creating old versions.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                               ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 135 of 159



Activity Audit Logging will be configurable in that a basic amount of system activity will
always be captured, but additional data can be captured and logged when
administrators or developers need to monitor different areas of the application in more
detail. The Activity Audit Logs will be useful to security administrators, system
administrators, applications developers, and other technical staff to help in forensics,
identifying problems, or in reconstructing end-user activity.

6C.6.6.2               System Activity Audit Logging Requirements
                                                                                                    Bidder
Requirement
                                             Requirement                                State Use   Agrees
Number
                                                                                                    (Y/N)
   972        The CCR System activity audit facility must allow an authorized           SUPP814
              administrator to set up different levels and types of activity logging.
   973        The CCR System activity audit facility must not allow anyone to turn      SUPP815
              off the required minimal level and minimal required type of activity
              logging.
   974        The minimal level and types of activity logging include:                  SUPP816
                 Each Business Service request/response,
                 Each Web Service SOAP request/response,
                 Each Business Process initiation and termination,
                 Data Access Layer service request/response, and
                 Each External Interface request/response.
   975        The CCR System must optionally log the following types and levels of      SUPP817
              activity, which can be enabled or disabled by an administrator:
                 SOAP request/response traces with full XML content and
                  headers,
                 Data Access layer service requests/response with full
                  request/response content and headers,
                 HTTP requests/response traces with full HTTP request and
                  response message (includes headers, content, URL),
                 WorkFlow steps with full Work Elements and Business Entity
                  Objects, and
                 Web Form Application Component invocation.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 136 of 159


                                                                                                     Bidder
Requirement
                                            Requirement                                  State Use   Agrees
Number
                                                                                                     (Y/N)
   976        The Activity Logging and Audit record must have a standard header          SUPP818
              with the following separately searchable fields:
                 Date: The date the event occurred.
                 Time: The local time the event occurred.
                 User: The user name of the user on whose behalf the event
                  occurred. This name is the client ID if the event was actually
                  caused by a server process, or the primary ID if impersonation is
                  not taking place. Where applicable, a security log entry contains
                  both the primary and impersonation IDs. Impersonation occurs
                  when Windows allows one process to take on the security
                  attributes of another.
                 Computer: The name of the computer where the event occurred.
                 ProcessID: The process ID where the event occurred.
                 Event ID: A number identifying the particular event type. Each
                  event type must have a description the description which contains
                  the name of the event type.
                 Source: The software component that logged the event, which
                  can be either a program name such as "SQL Server," or a
                  component of the system or of a large program such as a driver
                  name.
                 Type: A classification of the event severity: Error, Information, or
                  Warning in the System and application logs; Success Audit or
                  Failure Audit in the security log.
                 Category: A classification of the event by the event source. This
                  information is primarily used in the security log. For example, for
                  security audits, this corresponds to one of the event types for
                  which success or failure auditing can be enabled in Group Policy.
                 IP address or ANI: Client identifier (PC IP address or ANI).
                 Request ID: Service Request ID causing the Activity.
                 Session ID: Correlation/Session ID for Services causing the
                  Activity.
   977        The header properties definition must include field name, type, size,      SUPP819
              max length, and description of the data.
   978        If the application requires transaction management, the Activity           SUPP820
              logging must not rollback with an application rollback request.
   979        The CCR System activity audit facility must prevent use of any             SUPP821
              function in the System for which Activity logging is unsuccessful.



Security Logging is intended to only be accessible to security administrators who have
been granted access. The security logging should be ―always-on‖, with no ability to be
disabled, and not configurable to increase or decrease the level of logging.


1673D445-8846-415B-9B58-82958E8C824D.DOC                                                 ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 137 of 159



6C.6.6.3              Security Logging Requirements
                                                                                                  Bidder
Requirement
                                             Requirement                              State Use   Agrees
Number
                                                                                                  (Y/N)
   980        The CCR System security logging must include, but not be limited to:    SUPP822
                 Agent desktop authentication (successful or failed),
                 Web Authentication (successful or failed),
                 IVR Authentication (successful or failed),
                 Resource Access Violation-Data Validation exception,
                 Security Policy Rules Violation,
                 Business Rules validation exception,
                 Trust Delegation-Access grants and privileges changes,
                 Registration of users,
                 Add/change/remove roles,
                 Security Policy Changes, and
                 Security Audit services.
   981        The CCR System security logging must not allow a security               SUPP823
              administrator, database administrator, system administrator or any
              user to turn off Security Events Logging or change its settings.
   982        The security events logging must be in place 24 hours per day, seven    SUPP824
              (7) days per week.
   983        The CCR System security logging facility must prevent use of any        SUPP825
              function in the System for which Activity logging is not working.
   984        The CCR System must optionally log the following types and levels of    SUPP826
              activity, which can be enabled or disabled by an administrator:
                 SOAP request/response traces with full XML content and
                  headers,
                 Data Access layer service requests/response with full
                  request/response content and headers,
                 HTTP requests/response traces with full HTTP request and
                  response message (includes headers, content, url),
                 WorkFlow steps with full Work Elements and Business Entity
                  Objects,
                 Web Form Application Component invocation
   985        The header properties definition must include field name, type, size,   SUPP827
              max length, and description of the data.
   986        The CCR System security logging must write to the MS Windows            SUPP828
              Event log.
   987        The CCR System security logging must have a configurable option to      SUPP829
              write to user-specified files, in addition to MS Windows Event log.



1673D445-8846-415B-9B58-82958E8C824D.DOC                                              ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 138 of 159




6C.6.6.4               Requirements for Transfer of Security Logs
                                                                                                      Bidder
Requirement
                                             Requirement                                  State Use   Agrees
Number
                                                                                                      (Y/N)
   988        The Security Events Logs and Activity logs increments must be               SUPP830
              automatically transferred to the Central Archive server every N
              minutes, where N is configurable interval.
   989        The log increments transfers must be performed over secure channel          SUPP831
              encrypted by SSL or IPSEC.
   990        The Central Log Archive Server must store all logs in MS SQL Server         SUPP832
              Database.
   991        All Archived Log records must be signed in Central Archive Database         SUPP833
              by Central Archive Server during import operation. The signature must
              use SHA1, SHA256, or current federally approved hashing standard.
   992        The secure log archive server must only be accessible by authorized         SUPP834
              security personnel.
   993        Web browser access to the central log archive server must be done           SUPP835
              only via SSL.
   994        The central logs archive reporting infrastructure must have a Web           SUPP836
              browser based reporting mechanism for Activity and Security events
              logs so that no technical help will be required to interpret the activity
              and security logs archive.
   995        All header fields of Activity and Security Events logs must be saved as     SUPP837
              separate columns in database table(s).
   996        The central archived audit log infrastructure must allow reports by         SUPP838
              content keywords.
   997        The security audit data must not have any update/modification/delete        SUPP839
              privileges or capabilities for any users of Central Archive server.
   998        The Activity and Security Events Logs export must be a scheduled            SUPP841
              system activity that does not require user intervention.
   999        If a source server cannot communicate with the Central secure logs          SUPP842
              Archive during a scheduled file transfer, the source or target server
              must keep trying to send the data until the process is successful, and
              trigger a security alert that notifies administrative staff.
   1000       If a source server cannot communicate with the Central secure logs          SUPP852
              Archive during a scheduled file transfer, or the transfer fails for any
              reason, the system must generate a notification to security
              administrators.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                  ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                               SECTION 6C — PAGE 139 of 159



6C.6.7        Information Management
The database of record for UI continued claims data will be the CCR System. Due to the
high volume of transactions, the CCR System must include capabilities for archiving inactive
claims.

6C.6.7.1              General Information Management Requirements
                                                                                                Bidder
Requirement
                                          Requirement                               State Use   Agrees
Number
                                                                                                (Y/N)
   1001       All reporting systems must request data from non-transactional data   SUPP487
              stores, unless explicitly agreed to by the UIMOD and the Enterprise
              Architecture Office (EAO).
   1002       Mandatory/Optional                                                    SUPP488
              All transactional data must be replicated and/or transformed to
              secondary data stores that will be primarily focused on meeting the
              reporting needs of EDD.


6C.6.7.2              System Archiving Requirements
                                                                                                Bidder
Requirement
                                          Requirement                               State Use   Agrees
Number
                                                                                                (Y/N)
   1003       The CCR System must provide the ability to automatically archive      SUPP489
              data that is configurable by EDD.
   1004       The CCR System must be able to be synchronized with the SCDB          SUPP490
              archival.
   1005       The System must be able to store archived claims to separate long-    SUPP491
              term storage media and retrieve archived claims on demand.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                            ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 140 of 159



6C.6.7.3              Business Entity Requirements
The UIMOD project defines specific requirements for how data will be managed. All custom
development will use XML Data Objects (XDO). XDO is defined as a model based on the
concept of disconnected data graphs (Object Containers). XDO is not a single software
product, but a set of components, design patterns, products, frameworks, and services that
together provide the foundation capabilities required by the UIMOD project.
A data graph is a collection of tree-structured data objects (e.g. XML Documents). Under
the disconnected data graphs architecture, a client retrieves a data graph from a data
source, mutates the data graph, and can then apply the data graph changes back to the
data source. Each tree-structured data object in the data graph must support automatic XML
(de)serialization.

XDO is an advanced SOA Disconnected Data Programming Model based on optimistic
concurrency. All XML Data Objects have XML schemas which define the data object
structure, constraints, properties, validation rules, states and processing events/actions.
XML Data Objects are de-coupled from Data Sources.

                                                                                                  Bidder
Requirement
                                           Requirement                                State Use   Agrees
Number
                                                                                                  (Y/N)
   1006       The System must have a metadata repository that stores information      SUPP492
              about the Business Entities, Enterprise Services, and other system
              resources.
   1007       The Contractor must include a formal framework for implementation of    SUPP493
              Business Entities in their proposed solution.
   1008       Business Entities must map raw data from the database into an           SUPP494
              internal format to be used by other parts of the System.
   1009       Every Business Entity must implement serialization to and from XML      SUPP495
              using a SOAP Formatter and UTF-8 encoding.
   1010       Every Business Entity must implement serialization via a class          SUPP496
              serialization attribute or the iSerializable interface.
   1011       The Business Entity classes must be able to transform XML document      SUPP497
              representations of Business Entities to a Relational Model (table
              schemas) using mapping schema meta-objects defined in a metadata
              library (or Repository).
   1012       The Business Entity class must be able to encapsulate an XML            SUPP498
              document to maintain data as a dynamic structure and enable all XML
              manipulation functionality to Business Services code and Presentation
              code.
   1013       A Business Entity schema must support an XSD schema, an XML-to-         SUPP499
              relational data model mapping schema, an object template of initial
              values, resource schema data validation rules, and references to
              related business entities.
   1014       Every Business Entity must have, at a minimum, the type and XSD in      SUPP500
              a metadata repository to define the Business Entity type (data
              structure and properties).


1673D445-8846-415B-9B58-82958E8C824D.DOC                                              ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 141 of 159


                                                                                                       Bidder
Requirement
                                            Requirement                                    State Use   Agrees
Number
                                                                                                       (Y/N)
   1015       The CCR System must accept HTTP requests with URL referencing                SUPP501
              any XSD and return the specified XSD from the metadata repository.
   1016       The CCR System must not allow use of a Business Entity without               SUPP502
              Type and XSD or Data Object Schema.
   1017       Every Business Entity instance (object) must have a Globally Unique          SUPP504
              Identifier (ObjectID implemented as GUID type) to be used as primary
              key.
   1018       Every Business Entity must have the ability to create new instances          SUPP505
              (objects) and automatically initialize properties from existing objects or
              templates.
   1019       Every Business Entity instance (object) must have name unique                SUPP506
              among all objects of a same type.
   1020       All Business Entities must provide a way to view the entity as a             SUPP507
              human-readable XML text string to facilitate logging and
              troubleshooting.
   1021       The UIMOD system must use an optimistic concurrency disconnected             SUPP846
              programming model.
   1022       The UIMOD system must use a disconnected container of XML data               SUPP847
              objects (XDO).
   1023       The UIMOD Domain Object Model must meet the following                        SUPP848
              requirements:
              a) All meta-data, configurations, settings must have XML format.
              b) All Data Objects must be automatically (de)serialized to/from XML
              by .NET when passed to Web Service as arguments, and when
              passed automatically to other processes.
              c) The UIMOD may use few generic Business Entity class(es) to
              manipulate many Data Objects types described by Schemas.
              d) Data Objects have to be de-coupled from Data Sources.



6C.6.7.4               Data Access Layer Requirements
                                                                                                       Bidder
Requirement
                                            Requirement                                    State Use   Agrees
Number
                                                                                                       (Y/N)
   1024       The data access layer must hide the complexity and implementation of         SUPP508
              the logical and physical data from the business components.
   1025       The Data Access layer must be implemented as a set of.NET                    SUPP509
              Enterprise Services.
   1026       The Data Access layer must expose a Web Service interface.                   SUPP510
   1027       The Data Access layer must be able to cache objects.                         SUPP511
   1028       The Data Access layer must support a scrollable database cursor.             SUPP512



1673D445-8846-415B-9B58-82958E8C824D.DOC                                                   ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 142 of 159


                                                                                                 Bidder
Requirement
                                           Requirement                               State Use   Agrees
Number
                                                                                                 (Y/N)
   1029       The CCR System must provide a generalized data access interface        SUPP513
              that exposes functionality to search, read, write, update and delete
              business entities, enabled by changes to the metadata repository.



6C.6.7.5              Database Requirements
                                                                                                 Bidder
Requirement
                                           Requirement                               State Use   Agrees
Number
                                                                                                 (Y/N)
   1030        The CCR System must use the latest supported version of MS SQL        SUPP514
               server.
   1031        The CCR System must use a 64 bit Database.                            SUPP515
   1032        The CCR System Database technology must support optimistic            SUPP516
               concurrency.
   1033        All database access must be performed using a dedicated service       SUPP517
               account so database-level security will be based on the service
               account and not on individual user accounts.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                             ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 143 of 159



6C.6.8        System Operations
This section specifies quantitative requirements for system reliability and the conditions
under which reliability requirements must be met.

6C.6.8.1              System Human Factor Requirements
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   1034       The CCR System must edit all transactions for errors and provide          SUPP520
              immediate user feedback, including error messages and possible
              corrective actions.
   1035       The Web-based user interface for customer self-service transactions       SUPP521
              must be simple to operate and require no training for external users to
              perform customer self-service transactions.
   1036       The CCR System must support drop down menus (e.g., lists of values)       SUPP522
              for appropriate fields.
   1037       The CCR System must allow all lists of values for drop down menus to      SUPP523
              be edited by the Business Rules Administrator.
   1038       The CCR System must provide on-line user documentation that is            SUPP524
              indexed and searchable.
   1039       The CCR System must provide on-line help at the system, function,         SUPP525
              screen, and field level.



6C.6.8.2              General Maintainability Requirements
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   1040       The Contractor must build active application level monitoring of the      SUPP528
              entire System (or individual components) such that the System will be
              probing for these events and generate events that are recorded in the
              System logs. These events can then be identified and trigger operator
              activities.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 144 of 159



Disaster recovery requirements relative to the physical systems are not the
responsibility of the Contractor. The EDD will decide on a disaster recovery plan with
the hosting provider. The current expectation for the maximum amount of CCR system
downtime that EDD can tolerate is 24 hours.

6C.6.8.3              System Reliability Requirements
                                                                                                     Bidder
Requirement
                                            Requirement                                  State Use   Agrees
Number
                                                                                                     (Y/N)
   1041       The initial production configuration must provide 99.90 percent            SUPP529
              availability during scheduled hours. Availability is defined as the
              percent of time that the application is available for normal business
              operations during scheduled hours of operation.
   1042       The Contractor must design, build and configure the System so there        SUPP530
              is no single point of failure.
   1043       The CCR System‘s distributed infrastructure must provide for 24x7          SUPP531
              non-stop operations.
   1044       The Database Server must be configured as failover cluster.                SUPP532
   1045       Disruption (planned or unplanned) of any distributed server, service, or   SUPP533
              component must not interrupt active client‘s sessions.
   1046       Business Services must be stateless.                                       SUPP534
   1047       Web Servers session states must be maintained out-of-process,              SUPP535
              allowing Web servers to be load balanced.
   1048       The Web and Application Servers must be configured so that                 SUPP536
              additional servers can be added or removed with no system downtime.
   1049       The enterprise services bus (ESB) infrastructure must provide              SUPP537
              automatic retry of every failed Service request, and retry operations
              have to be controlled by the ESB configuration.
   1050       All errors must be logged to an event log and trace file.                  SUPP538
   1051       Pacing/Throttling must be implemented to prevent overrun of                SUPP539
              memory/work queues.
   1052       Each function of every component or class which may receive an             SUPP540
              exception must include code for gathering information about the
              exception, in adequate detail to allow an application developer to see
              the details of the exception.
   1053       Every trapped exception must write adequate debugging and                  SUPP542
              environment information to an event log for use by operations
              management tools.
   1054       Every trapped exception must write adequate debugging and                  SUPP543
              environment information to facilitate production application debugging
              by application support personnel.
   1055       Each function of every component/class must have calls to                  SUPP544
              Instrumentation Framework TRACE sink (or functionally equivalent
              trace) at the entry and exit point to record error information for
              debugging of production applications.


1673D445-8846-415B-9B58-82958E8C824D.DOC                                                 ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 145 of 159


                                                                                                     Bidder
Requirement
                                            Requirement                                  State Use   Agrees
Number
                                                                                                     (Y/N)
   1056       The level and types of tracing must be controlled externally (not          SUPP545
              embedded in the software) for each server, service, and application.
              The level and type will allow external control over the amount and type
              of trace data that is available for troubleshooting or system health
              monitoring.
   1057       Exception handling code should include logic, where applicable, to         SUPP862
              retry the tasks that resulted in an exception, in addition to generating
              debugging and environment information for analysis.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                 ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 146 of 159



6C.6.9        Design Constraints
This section documents requirements that restrict the design to the System. This includes
physical requirement, performance requirements, software development standards and
software quality assurance standards.

6C.6.9.1              General System Design Constraints
                                                                                                    Bidder
Requirement
                                            Requirement                                 State Use   Agrees
Number
                                                                                                    (Y/N)
   1058       The user interface design of screens and forms must conform with the      SUPP552
              EDD style guide. (See Bidders' Library, Reference Miscellaneous
              folder, EDD Enterprise Internet Style Guide.)
   1059       The System must support the two most recent versions of popular           SUPP553
              Web browsers (Opera, Internet Explorer, Firefox, Mozilla, Safari, and
              Netscape) at the time the system is moved to production.
   1060       All user interface features must work in a similar fashion on the two     SUPP554
              most recent versions of the popular Web browsers (Opera, IE, Firefox,
              Mozilla, Safari, and Netscape) at the time the System is moved to
              production.
   1061       All custom software development of the CCR System must be built           SUPP555
              using the Microsoft.NET framework.
   1062       The Customer facing web applications must disable the "Auto-Fill"         SUPP850
              form capability so that sensitive information entered by claimants will
              not be available to subsequent users on PCs used in a public "kiosk"
              type of environment.
   1063       The CCR System will be an n-tier Service Oriented Architecture (SOA)      SUPP856
              application using the Microsoft .NET framework.
    1063A     All CCR System software developed for the .NET platform must be           SUPP519
              written in C#.
    1063B     All custom software development of the CCR System must be                 SUPP865
              performed using the MS .NET 3.0 or higher and only the following
              programming languages: C#, XML, C# Script, SQL, BRF Rules
              language, and JavaScript for Web Pages.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                               SECTION 6C — PAGE 147 of 159



6C.6.10       Architecture Requirements
Application model requirements include requirements for reusability/extensibility, layered
models, Enterprise Services and reusable infrastructure components.

6C.6.10.1             Design Requirements to Support Performance and Scalability
                                                                                               Bidder
Requirement
                                          Requirement                              State Use   Agrees
Number
                                                                                               (Y/N)
   1064       Each Business Service must use COM+ Object Pooling.                  SUPP558
   1065       Each Business Service must be stateless.                             SUPP559
   1066       The CCR System must enable Web Forms to use technology to            SUPP560
              perform asynchronous server processing of web controls (e.g. Atlas
              technology or AJAX).
   1067       Web Forms must be developed as asynchronous ASP.NET server           SUPP561
              pages.
   1068       Business Services must be consumed via an asynchronous interface.    SUPP562
   1069       The data Access layer must provide an asynchronous interface.        SUPP563
   1070       The CCR System‘s Web servers must be configured for HTTP             SUPP564
              compression.
   1071       The CCR System must be designed to be available for transaction      SUPP565
              processing during any required batch processing.



6C.6.10.2             Reusability / Extensibility Requirements
                                                                                               Bidder
Requirement
                                          Requirement                              State Use   Agrees
Number
                                                                                               (Y/N)
   1072       The CCR System must support component reusability and                SUPP566
              extensibility.
   1073       The CCR System must support the use of XML meta data to register     SUPP567
              and un-register components that can be dynamically added and/or
              removed.
   1074       The CCR System must support pluggable/extensible services.           SUPP568



6C.6.10.3             Layered Model Requirements
                                                                                               Bidder
Requirement
                                          Requirement                              State Use   Agrees
Number
                                                                                               (Y/N)
   1075       Every Business Service must be implemented as.NET Enterprise         SUPP571
              Service.
   1076       Every Business Service must expose a Web Service Interface.          SUPP572
   1077       The CCR System must use MSMQ or WMQ for reliable asynchronous        SUPP573
              messaging.

1673D445-8846-415B-9B58-82958E8C824D.DOC                                           ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 148 of 159


                                                                                                   Bidder
Requirement
                                            Requirement                                State Use   Agrees
Number
                                                                                                   (Y/N)
   1078       All clients must invoke Business Services only via the Business          SUPP574
              Façade.
   1079       The CCR System and other applications must use SOAP as standard          SUPP575
              message format for service requests.
   1080       The middleware framework must support ―Drain‖ and ―Shutdown‖             SUPP576
              service for any and all servers.
   1081       The middleware framework must support dynamic ―Enable‖ and               SUPP577
              ―Disable‖ services for any Business Service.
   1082       All Business Service Façade functions must log the entry and exit from   SUPP578
              the function to assist with diagnosis, tuning, and analysis.
   1083       Each Business Service must expose a public interface containing a set    SUPP582
              of ―top-level‖ methods, which will be callable from the Business
              Façade Layer or from other Business Services. All implementation
              details of the Business Service will be hidden behind this public
              interface.
   1084       Business Services must implement transaction management and              SUPP583
              rollback functionality required to perform their tasks correctly and
              ensure the integrity of the resources they access.



Layered model requirements include requirements related to the presentation, business
services, workflow, business entities and the data access layer.
Requirements for enterprise services and reusable infrastructure components include
requirements for enterprise service bus (ESB), enterprise repository, exception
management and logging, instrumentation, data modeling, data integrity, storage, data
migration, time stamping of data and archiving of data.

6C.6.10.4             Requirements for Enterprise Services and Reusable
                      Infrastructure Components
                                                                                                   Bidder
Requirement
                                            Requirement                                State Use   Agrees
Number
                                                                                                   (Y/N)
   1085       The CCR System must include an Enterprise Service Bus (or                SUPP585
              integration broker infrastructure).
   1086       The ESB must support Web Service Description Language (WSDL)             SUPP586
              which specifies how a requesting component binds with a service
              component.
   1087       The ESB must support a location and transport independent                SUPP587
              mechanism for integration of the components that hides the
              complexities associated with location of where the service is provided
              and transport schema from the requesting component.
   1088       The ESB/Request Adapter must be used for authentication of the           SUPP588
              caller using the common authentication infrastructure.

1673D445-8846-415B-9B58-82958E8C824D.DOC                                               ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 149 of 159


                                                                                                   Bidder
Requirement
                                            Requirement                                State Use   Agrees
Number
                                                                                                   (Y/N)
   1089       The ESB/Request Adapter must be used for transforming external           SUPP589
              information into a canonical format or if outgoing, to the format
              required by the requesting application.
   1090       The ESB/Request Adapter must support both asynchronous and               SUPP590
              synchronous messaging.
   1091       The ESB/Request Adapter must support both persistent/transactional       SUPP591
              message queue and batch processing.
   1092       The CCR System must include standards for business message               SUPP592
              specifications and formats.
   1093       The Business Message must contain all of the information necessary       SUPP593
              to execute a particular requested service. This information must, at a
              minimum, include the service to be called, the function to be invoked,
              information about the calling user/machine, contextual information
              including session/security information, simple and complex type input
              parameters to the function being invoked.
   1094       The CCR System must support an Enterprise Registry for registration      SUPP594
              of business entities and services.
   1095       The CCR System must provide an Enterprise Service for exception          SUPP595
              management and logging.
   1096       The CCR System must include an Enterprise Service for                    SUPP596
              instrumentation of components.
   1097       New information objects must be synchronized with the existing SCDB      SUPP597
              database to ensure that integrity between new and legacy data is
              maintained.



6C.6.10.5             Detailed Enterprise Service Bus Requirements
                                                                                                   Bidder
Requirement
                                            Requirement                                State Use   Agrees
Number
                                                                                                   (Y/N)
   1098       The ESB must support .NET/Java interoperability and interaction of       SUPP702
              distributed services across the Microsoft .NET and IBM Websphere
              application server environments.
   1099       The ESB must support running services and applications at physically     SUPP703
              separate locations, using different application server environments
              (e.g. .NET and Websphere).
   1100       The ESB must provide a Web Services Registry-Repository for              SUPP704
              building Service-Oriented Architectures (SOA).
   1101       The Services Registry must provide interface(s) to register, discover,   SUPP705
              and manage services for any Service-Oriented infrastructure.
   1102       The ESB must ensure that services in the registry conform to Web         SUPP706
              Services Interoperability (WS-I) standards.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                               ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 150 of 159


                                                                                                     Bidder
Requirement
                                            Requirement                                  State Use   Agrees
Number
                                                                                                     (Y/N)
   1103       The Service Registry functions have to support not only discovery and      SUPP707
              reuse of services, but also discovery and reuse of other SOA metadata
              and objects (such as XSD files).
   1104       The ESB must ensure that registering and discovering web services,         SUPP708
              and managing associated metadata and objects (such as XSD files) is
              performed securely.
   1105       The Services Registry/Repository must support UDDI 3.0 and ebXML           SUPP709
              Registry 3.0 or more current standards.
   1106       The ESB must ensure that services in the registry conform with             SUPP710
              referenced schemas.
   1107       The ESB Registry must allow documentation to be added and                  SUPP711
              appended to SOA metadata and objects, to facilitate discovery and
              understanding of services and related functionality.
   1108       The ESB must provide the ability to register, discover, and govern Web     SUPP712
              services and other metadata.
   1109       The ESB Registry must support publishing, management, governance,          SUPP713
              discovery and reuse of Web Services and related SOA Artifacts.
   1110       The ESB Registry must provide a hierarchical classification (taxonomy)     SUPP714
              scheme for managing and grouping services and other SOA metadata.
   1111       The ESB Registry must provide information artifact discovery using         SUPP715
              domain-specific queries (SQL, XML filter query syntax).
   1112       The ESB Registry must provide validation of information artifacts using    SUPP716
              domain-specific business rules.
   1113       The ESB Registry must provide version control, life cycle management       SUPP717
              and governance of all information objects contained in the ESB
              Registry.
   1114       The ESB Registry must provide standard and user-defined taxonomies         SUPP718
              that may be used to classify information artifacts.
   1115       The ESB Registry must provide the ability to define formal links           SUPP719
              between information artifacts. With these links, queries on the Registry
              will allow related artifacts to be found.
   1116       The ESB Registry must provide notification of changes to information       SUPP720
              artifacts to subscribers.
   1117       The ESB Registry must provide custom, fine-grained role based              SUPP721
              access control.
   1118       The ESB Registry must provide a complete audit trail / event log of        SUPP722
              changes to information artifacts.
   1119       The ESB Registry must be remotely configurable and remotely                SUPP723
              manageable.
   1120       The ESB must support extending components as services.                     SUPP724
   1121       The ESB must support event-driven Services.                                SUPP725



1673D445-8846-415B-9B58-82958E8C824D.DOC                                                 ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 151 of 159


                                                                                                         Bidder
Requirement
                                             Requirement                                     State Use   Agrees
Number
                                                                                                         (Y/N)
   1122       The ESB must support clustering of local service invocations, initiated        SUPP726
              with a single remote message.
   1123       All updates and upgrades to the ESB must not affect anything attached          SUPP727
              to endpoints (such as services, applications, or extending
              components).
   1124       The ESB must be deployed on Microsoft Windows .NET platform.                   SUPP728
   1125       The ESB must support a configurable, dynamic interface to use a                SUPP729
              Business Activity Monitoring (BAM) tool.
   1126       The ESB must support a configurable, dynamic interface to use an               SUPP730
              external (to the ESB) Business Rules Tool and Engine.
   1127       The ESB must provide functionality that allows ESB administrators to           SUPP731
              orchestrate services that ESB clients (endpoints) access such that the
              clients do not require changes. Orchestration is defined as the
              managing of service usage, including tasks such as re-routing from
              one service to another, combining multiple services into one, or
              changing the physical location of a service.
   1128       The ESB must provide an interface that allows a standard client                SUPP732
              interface (an ―endpoint‖) for building and invoking services managed
              by the ESB.
   1129       All services must be hosted by Service Containers which must provide           SUPP733
              a standard interface.
   1130       All Service Containers must have the ability to be extended by                 SUPP734
              additional ESB functionality.
   1131       The Service Container must provide logging and auditing services.              SUPP735
   1132       The ESB must support both synchronous and asynchronous                         SUPP736
              messaging.
   1133       The ESB must support messages that are sent and received either by             SUPP737
              methods that guarantee delivery or methods that do not guarantee
              delivery.
   1134       The ESB must support the ability to turn XML compression on and off.           SUPP738
   1135       The ESB must support both Point-to-Point and Multi-Point                       SUPP739
              (Publish/Subscribe) message queues.
   1136       The ESB must support publish/subscribe queues by "topic" (i.e. rather          SUPP740
              than send a message to many destinations, the destinations can
              "subscribe" to a topic and be automatically notified), with a related
              capability to manage the lists publishers/subscribers to each queue.
   1137       The ESB must support topic hierarchies, such that if a service is              SUPP741
              subscribed to a top-level topic, all notifications to sub-topics of the root
              topic will automatically be sent to the subscriber.
   1138       The ESB must validate SOAP arguments against schemas (for those                SUPP742
              arguments) in the registry.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                     ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 152 of 159


                                                                                                     Bidder
Requirement
                                            Requirement                                  State Use   Agrees
Number
                                                                                                     (Y/N)
   1139       The ESB must support XSL-based transformation and enrichment of            SUPP743
              objects. (An example of enrichment is adding the 4 digit suffix to zip
              codes).
   1140       The ESB must support validating XML messages for correct form and          SUPP744
              syntax.
   1141       The ESB must support specifying message validation that can – based        SUPP745
              on the message ―rules‖ – modify the message so that it conforms to
              the specified rules.
   1142       The ESB must support content-based routing, to both manage the             SUPP746
              routing of messages, and to ensure that the messages are routed
              securely.
   1143       The ESB must support Itinerary-Based Routing (i.e. the ―itinerary‖ for a   SUPP747
              service request is contained in the ESB Registry).
   1144       The ESB must have the capability to define and manage human (i.e.          SUPP748
              processes that involve human interaction) and business process
              workflows.
   1145       The ESB must have the ability to manage the itinerary (how the inputs      SUPP749
              and outputs of services are sequenced and orchestrated) for
              messages that have one (1) or more process steps.
   1146       The Business Process Orchestration component must be capable of            SUPP750
              defining workflow rules in such a fashion that workflow rules are
              configurable from parameters and/or tables.
   1147       The Business Process Orchestration component must support the use          SUPP751
              of message itineraries and business process workflows constructed in
              conformance with the BPEL4WS standard.
   1148       The Business Process Orchestration component must support the WS-          SUPP752
              Coordination standard.
   1149       The ESB must support multiple communication protocols for                  SUPP753
              SOAP/XML messages, including current standard versions of TCP,
              HTTP, HTTPS, WMQ, and MSMQ.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                 ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 153 of 159


                                                                                                  Bidder
Requirement
                                             Requirement                              State Use   Agrees
Number
                                                                                                  (Y/N)
   1150       The ESB must be based on open, industry-accepted standards, such        SUPP754
              as current standard versions of:
                   ebXML Registry 3.0,
                   UDDI 3.0,
                   SOAP 1.1 with Attachments,
                   WSDL 1.1,
                   XML Signature 1.0,
                   XSLT 1.0,
                   Web Services Security: SOAP Message Security 1.0,
                   Web Services Security: SOAP Message with Attachments (SwA)
                    Profile 1.0,
                   XSD,
                   XPath,
                   XQuery,
                   BPEL4WS,
                   WS-Policy, and/or
                   XML-Encryption.
   1151       The ESB must support both local and distributed transactions.           SUPP755
   1152       The ESB must support a hierarchical transaction model with              SUPP756
              'compensating transaction' rollback, as well as the traditional flat
              transaction model.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                              ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 154 of 159



6C.6.10.6             Content Change Capability Requirements
                                                                                                     Bidder
Requirement
                                            Requirement                                  State Use   Agrees
Number
                                                                                                     (Y/N)
   1153       The CCR System software must be built such that business analysts          FCTN1293
              can change the text, titles and labels on Web forms within the
              framework of a governance process that protects the integrity of the
              form and workflow.
   1154       The CCR System must follow a formalized change control process or          FCTN1294
              workflow for changes to text, titles, and labels shared by the IVR, the
              Web applications, and paper-based forms. The intent of this is to force
              all changes to follow a pre-defined authorization process prior to being
              moved to the production environment.
   1155       The CCR System must share messages, titles and labels between the          FCTN1295
              IVR, Web and paper-based forms. A single change must
              automatically update all three channels.
   1156       Messages, titles and labels shared by the IVR, Web and paper-based         FCTN1296
              forms in the CCR system must be built to support multiple languages.



6C.6.10.7             Workload Management Synchronization Requirements
                                                                                                     Bidder
Requirement
                                            Requirement                                  State Use   Agrees
Number
                                                                                                     (Y/N)
   1157       Calls and work queues must be managed according to availability,           FCTN1297
              permissions and skills (including fraud associated skills and level of
              training) associated with each agent identified to the system.
   1158       The availability, permissions and skills associated with each agent        FCTN1298
              identified to the System must be available for the distribution of work
              whether the work items are call related or non-call related (e.g.
              payment exceptions, determination interviews).



6C.6.10.8             Data Conversion Requirements
                                                                                                     Bidder
Requirement
                                            Requirement                                  State Use   Agrees
Number
                                                                                                     (Y/N)
   1159       The CCR System must detect when data on the legacy system - not            SUPP648
              converted as part of the initial data conversion of active claims -- has
              been made 'active'. The CCR System must convert that data for use
              on subsequent transactions.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                 ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                       RFP OSI 7100-181
UIMOD PROJECT                                           SECTION 6C — PAGE 155 of 159



6C.6.11       Business Rules Framework

It is the goal of UIMOD Project to acquire and install a Business Rule Framework (BRF) that
provides the following general capabilities "out of the box" without the use of custom
code.
Definition and management of a set of business rules, including tools to allow these tasks to
be performed by non-technical personnel (power users like functional analysts).
     1. Processing of those rules against data made available to the BRF engine.
     2. Providing output in the form of decisions, traces and data entities based on rule
        processing.
     3. Auditing of the rule set through Audit, Analysis & Reporting tools.

The business rule framework is anticipated to be used throughout Employment
Development Department‘s (EDD) operational areas. An example of this is the first
intended application, which involves automation of the continued claim processing (eligibility
verification, authorization, and adjudication workflow). Once EDD receives a UI claim
application, there are two (2) levels of eligibility determined (monetary and separation)
and requirements governing subsequent eligibility (non-separation) are established
based on responses to questions in the claim application. Whenever there is a question
of compliance with an eligibility requirement, an interview with Department staff is required.
As this drives the entire life-cycle of the claim, any steps to reduce the lag time between the
detection of eligibility issues and determination are beneficial to all parties. In the legacy
environment there are limitations in the system‘s ability to detect non-compliance due to the
fact that not all of the necessary questions are asked. In these cases the claim is halted
until EDD staff obtain the necessary ―clarification‖ at which point the claim continues through
authorization of payment or the determination interview is scheduled.
In the projected CCR application, rule sets that govern eligibility are expected to operate at
two (2) levels. At the first level they are expected to establish what some of the eligibility
requirements are (e.g. if you belong to a union that does not send you out to jobs then you
must look for work on your own). The second level of rules would then evaluate if you have
complied with your requirements (e.g. did you look for work during this week). The rules
would also govern if the question even needed to be asked (e.g. If you are not required to
look for work the system should not ask you that question).
The Audit & Reporting system will store and display the results of each transaction, and
a modeling engine will perform "what if‖ scenarios to allow rule changes to the application.
The selected Contractor will be required to provide the Business Rule Framework
software product, as well as the expertise to install the product at EDD and provide full
documentation and knowledge transfer of that product to EDD personnel.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                          ADDENDUM 3      APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 156 of 159



6C.6.11.1             Basic Functionality Requirements
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   1160       The BRF must allow rule creation, alteration, removal and version         SUPP658
              control.
   1161       The BRF must provide interface for rule creation, alteration, and         SUPP659
              removal as an abstraction layer from underlying code set.
   1162       The BRF rules language must be object-oriented, operate on objects,       SUPP660
              tables and XML documents.
   1163       The BRF rules language must support objects methods, properties,          SUPP661
              indexers and object iterators for any .NET object type.
   1164       The BRF must store input and results data of each rule set transaction    SUPP662
              in RDBMS for Audit, Analysis & Reporting and trending purposes.
   1165       The BRF must store rule sets processing trace with the detailed           SUPP663
              rationale for each rule decision in RDBMS for Audit, Analysis &
              Reporting purposes.
   1166       The BRF must operate with Microsoft operating systems (Windows            SUPP664
              2000/2003 Server and later).
   1167       The BRF must fit within EDD architecture guidelines and use MS SQL        SUPP665
              Server as the rules repository.
   1168       The BRF must allow large lookup tables (up to 10,000 records) to          SUPP666
              match with input data fields, with performance of such lookup tables to
              match similar application written in MS C#.
   1169       The BRF must be able to perform math calculations on input fields,        SUPP667
              including integer, long, double, date and time calculations. The BRF
              math calculation engine must provide all functions available in
              standard .NET C# Math class.
   1170       The BRF rule sets can be deployed and used as .NET components,            SUPP668
              COM+ Enterprise Services, Web Services and batch application
              processes.
   1171       The BRF must allow the creation of complex rule sets, including           SUPP669
              nested decision trees, which would allow more flexibility than an
              ―either/or‖ decision; including complex expressions and formulas,
              assertions and constraints.
   1172       The BRF must allow rule sets to include other rule sets and call other    SUPP670
              rule sets.
   1173       The BRF solution must be based on a commercially available                SUPP671
              packaged business rule framework, rather than custom code built
              "from scratch" solely designed for the CCR application.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 157 of 159



6C.6.11.2             Decision Component
The selected product will be required to process transactions through a decision or rule
engine. The first intended application for the Business Rule Framework is CCR, to be
based on the specifications below.

6C.6.11.3             Decision Component Requirements
                                                                                                     Bidder
Requirement
                                            Requirement                                  State Use   Agrees
Number
                                                                                                     (Y/N)
   1174       The inputs, results of each transaction and the detailed trace of          SUPP672
              rationale behind them must be logged for the Audit & Reporting
              System.
   1175       Any continued claims not filtered must be checked against a business       SUPP673
              rule set and logically categorized. That information must be used in the
              CCR application to assign resources and begin processes.
   1176       The Business rules must access and utilize data from any Web               SUPP674
              Services, ODBC RDBMS, and existing .NET components to
              validate/process the incoming data.



6C.6.11.4             Audit & Reporting
Using the CCR application as an example, the Audit and Reporting component will be
expected to perform based on the specifications below. The selected product will be
expected to allow this functionality.

6C.6.11.5             Audit & Reporting Requirements
                                                                                                     Bidder
Requirement
                                            Requirement                                  State Use   Agrees
Number
                                                                                                     (Y/N)
   1177       The BRF must capture and store rules input/output data on                  SUPP675
              transactions from the Decision (1.2) and Modeling (1.4) components.
   1178       The BRF must capture rules trace data with rationale for each rule         SUPP676
              action/decision and store in MS SQL Server based Archival system.
              The rules trace must capture every rule execution and result.
   1179       The BRF Audit component must allow the authorized users to search          SUPP677
              for transactions by any of the input/output fields being stored.



6C.6.11.6             Design, Modeling & Deployment Component Requirements
Requirement                                                                                          Bidder
Number                                      Requirement                                  State Use   Agrees
                                                                                                     (Y/N)
   1180       The BRF must allow users to run "what if?" scenarios by altering,          SUPP678
              removing, or adding rules to the rule sets.



1673D445-8846-415B-9B58-82958E8C824D.DOC                                                 ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 158 of 159


Requirement                                                                                         Bidder
Number                                      Requirement                                 State Use   Agrees
                                                                                                    (Y/N)
   1181       The BRF Design, Modeling, & Deployment components must be                 SUPP679
              operable without technical training or knowledge as the primary user
              will be of a non-technical or business nature. Technical personnel will
              also use this BRF component and must design meta-data for BRF use.
              (The use of Web browser, "wizards" or a similar abstraction layer to
              provide an online business user interface to make these changes is
              preferred.).
   1182       The BRF Rule changes must be run against a data set to be provided        SUPP680
              by EDD. The data set may be changed as business conditions or rule
              additions warrant.
   1183       The BRF Design, Modeling, & Deployment components must also be            SUPP681
              used to stage rule changes to the production environment. This is to
              be accomplished without manual re-coding, and with minimal IT
              involvement.
   1184       The BRF Design, Modeling, & Deployment components must store the          SUPP682
              history of rule changes made, allowing the user to return to earlier
              versions of rule sets, run them against the data set, and stage them to
              production as needed. This will require a version control feature.
   1185       The BRF must provide the ability to create an impact analysis for a       SUPP683
              potential business rule change, in terms of what other business rule
              objects will be affected.
   1186       The BRF must maintain a revision history for every change that occurs     SUPP684
              to business rule sets.
   1187       The BRF must generate a report containing a detailed list of changed      SUPP685
              business rule set objects at the user‘s request.
   1188       The BRF must provide the ability to version all business rule set         SUPP686
              objects including imported business rule sets.
   1189       The BRF must provide a work flow management facility that is used to      SUPP687
              guide a rule set change request through a business rule governance
              process.
   1190       The BRF must support the use of rule set templates that can be re-        SUPP688
              used, containing placeholder positions for missing information.
   1191       The BRF must be able to run multiple versions of rule sets,               SUPP689
              determining the specific rule set version based on rule set effective
              dates (for example) the date that a continued claim was created or
              submitted.
   1192       The BRF must support time periods for when the rule is active. This       SUPP690
              translates to support of an activation date for applying the rule and a
              termination date for when the rule is no longer applied. These time
              frames are to be applied to the time frame of the target object (a
              continued claim for instance).




1673D445-8846-415B-9B58-82958E8C824D.DOC                                                ADDENDUM 3           APRIL 8
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 159 of 159



6C.6.11.7             Product Architecture Requirements
                                                                                                   Bidder
Requirement
                                           Requirement                                 State Use   Agrees
Number
                                                                                                   (Y/N)
   1193       The BRF rule processing facility must have the ability to dynamically    SUPP691
              request additional information, and make multiple passes through the
              rule sets once necessary data is supplied.
   1194       The BRF must use a Meta-model Repository based on an SQL Server          SUPP692
              database to store and retrieve rule sets, meta-data, test data, etc.
   1195       The BRF must provide Web Services (SOAP) interfaces for all rule         SUPP693
              sets in order to use rule sets as Web Services and be invoked by any
              applications and exchange data and return decision results.
   1196       The BRF must allow rule sets to run concurrently in order to increase    SUPP694
              throughput and/or decrease processing time.



6C.6.11.8             Performance & Goals Requirements
                                                                                                   Bidder
Requirement
                                            Requirement                                State Use   Agrees
Number
                                                                                                   (Y/N)
   1197       The BRF product must be able to process up to 52,000 continued claims    SUPP695
              per hour through the Decision component using both batch and real-time
              methods, and provide results to EDDs application components.
   1198       The BRF product must be able to function in a "24x7" environment as      SUPP696
              claims must be processed continuously. This means that the product
              must include failover and fault-tolerant capabilities.




1673D445-8846-415B-9B58-82958E8C824D.DOC                                               ADDENDUM 3           APRIL 8

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:5
posted:7/19/2011
language:English
pages:159
Description: Proposed Jobs Lookup Template document sample