Prospect Question Template Excel by ryj16483

VIEWS: 19 PAGES: 178

More Info
									               OFFICE OF SYSTEMS INTEGRATION

               REQUEST FOR PROPOSAL OSI 7100-181
                  UNEMPLOYMENT INSURANCE
                   MODERNIZATION PROJECT




            SECTION 6C – TECHNICAL REQUIREMENTS




                                      March 23, 2007

                                           ISSUED BY:

                                    STATE OF CALIFORNIA

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




0074d5a5-617a-4ce3-91b8-4e162e2964d1.doc
OFFICE OF SYSTEMS INTEGRATION                                                                   RFP OSI 7100-181
UIMOD PROJECT                                                                         SECTION 6C — PAGE 2 of 178



                             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 ................................................... 13
6C.1.3      CCR Functional Requirements ....................................................................... 17
6C.2 SYSTEM INTERFACES .................................................................................... 37
6C.2.1 Overview of External System Dependencies .................................................. 38
6C.2.2      Global Interface Requirements ....................................................................... 41
6C.2.3      Detailed Integration Requirements .................................................................. 43
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..................................................................................... 80
6C.4.2      Day-to-Day Management ................................................................................ 80
6C.4.3      Business Planning Information........................................................................ 81
6C.4.4      Decision Support Information .......................................................................... 81
6C.4.5      Business Intelligence and Reporting: Tools Requirements ............................ 81
6C.4.6      Business Intelligence and Reporting: Constraining Requirements ................. 84
6C.4.7      Business Intelligence and Reporting: Ad-hoc Reporting Requirements .......... 85
6C.4.8      Business Intelligence and Reporting: Standard Reporting Requirements........ 86
6C.4.9      Business Intelligence and Reporting: Data Requirements .............................. 90
6C.5 CCNPAU REQUIREMENTS .............................................................................. 94
6C.5.1 Equipment ...................................................................................................... 94
6C.5.2      Network .......................................................................................................... 94
6C.5.3      Major System Constraints ............................................................................... 94
6C.5.4      System Availability .......................................................................................... 95
6C.5.5      System Capacity ............................................................................................. 96
6C.5.6      Enterprise UCD Requirements ........................................................................ 98
6C.5.7      800 Number Requirements ............................................................................. 99
6C.5.8      Skills-Based Routing ....................................................................................... 99
6C.5.9      Telephony Requirements ................................................................................ 99
6C.5.10 UCD Configuration Update Requirements .................................................... 103
6C.5.11 Operational Management Requirements....................................................... 103
6C.5.12 Back-Up and Recovery Requirements .......................................................... 104
6C.5.13 General Technical Requirements .................................................................. 104
0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                                                            MARCH 23,
OFFICE OF SYSTEMS INTEGRATION                                                                 RFP OSI 7100-181
UIMOD PROJECT                                                                       SECTION 6C — PAGE 3 of 178



6C.5.14 Performance Characteristics Requirements .................................................. 105
6C.5.15 Information Management .............................................................................. 105
6C.5.16 System Operations Requirements ................................................................ 106
6C.5.17 System Human Factors Requirements ......................................................... 106
6C.5.18 System Maintainability .................................................................................. 106
6C.5.19 Equipment and Software Requirements ........................................................ 107
6C.5.20 Architectural Design Requirements - VoIP Solution ...................................... 107
6C.5.21 Network Diagrams ........................................................................................ 109
6C.5.22 Management and Administration .................................................................. 113
6C.5.23 Equipment .................................................................................................... 114
6C.5.24 Telecommunications Capacities ................................................................... 120
6C.5.25 Architectural Considerations ......................................................................... 123
6C.5.26 System Security Requirements ..................................................................... 129
6C.6 CONTINUED CLAIMS REDESIGN REQUIREMENTS .................................... 132
6C.6.1 Major System Conditions .............................................................................. 133
6C.6.2      Operational Scenarios .................................................................................. 136
6C.6.3      System Performance Characteristics ............................................................ 137
6C.6.4      Adaptability and Extensibility......................................................................... 139
6C.6.5      System Security ............................................................................................ 143
6C.6.6      Audit Logging ................................................................................................ 152
6C.6.7      Information Management .............................................................................. 159
6C.6.8      System Operations ....................................................................................... 162
6C.6.9      Design Constraints ....................................................................................... 165
6C.6.10 Architecture Requirements............................................................................ 166
6C.6.11 Business Rules Framework .......................................................................... 174




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                                                         MARCH 23,
OFFICE OF SYSTEMS INTEGRATION                                                            RFP OSI 7100-181
UIMOD PROJECT                                                                  SECTION 6C — PAGE 4 of 178



                              Table of Figures
                    Section 6C – Technical Requirements

FIGURE 6C.1 OPERATIONAL REPORTING AND BUSINESS INTELLIGENCE
            ENVIRONMENT .............................................................................................79
FIGURE 6C.2 VOICE OVER INTERNET PROTOCOL CONFIGURATION ...................... 108
FIGURE 6C.3 CONCEPTUAL PROCESS ARCHITECTURE............................................ 125
FIGURE 6C.4 VOICEXML COMPONENTS ....................................................................... 126




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                                                  MARCH 23,
OFFICE OF SYSTEMS INTEGRATION                                                        RFP OSI 7100-181
UIMOD PROJECT                                                              SECTION 6C — PAGE 5 of 178



                       Table of Tables
             Section 6C – Technical Requirements

TABLE 6C.1   SYSTEM MODES AND STATES AT INITIAL IMPLEMENTATION..............95
TABLE 6C.2   STAFFING AND PHONES .............................................................................97
TABLE 6C.3   CALIFORNIA POPULATION DATA AND PROJECTIONS FROM US
             CENSUS BUREAU...................................................................................... 139
TABLE 6C.4   CALIFORNIA WORKFORCE AND UNEMPLOYMENT RATES................ 139
TABLE 6C.5   CALIFORNIA UI CONTINUED CLAIMS WORKLOAD AND
             PERFORMANCE......................................................................................... 140




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                                                MARCH 23,
OFFICE OF SYSTEMS INTEGRATION                                       RFP OSI 7100-181
UIMOD PROJECT                                             SECTION 6C — PAGE 6 of 178




6C       TECHNICAL REQUIREMENTS
During the course of the RFP development, the Call Center Network Platform and
Application Upgrade (CCNPAU) subproject and Continued Claims Redesign (CCR)
subproject worked independently and created separate sets of requirements. However, it
became clear that there are areas of overlap where the two (2) subprojects share
complimentary requirements. An example of this is the Interactive Voice Response (IVR)
system. While the IVR infrastructure requirements have been defined by the CCNPAU
subproject, the CCR subproject specifies functional requirements that require delivery to
end-users on both the channels – IVR and Internet.
Because of these shared areas, 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
          the two (2) subprojects. While not all of the functional requirements apply to
          both delivery channels many are common to both the Internet and the IVR.
       b) Continued Claims Functional Requirements – The functional requirements
          address the initial and subsequent releases of the certification process.
          These requirements were obtained from both subprojects.
       c) CCR Functional Requirements – These requirements are specific functionality
          for the CCR subproject.
     2. System Interfaces – both the IVR and the Internet 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
        CCNPAU subproject
     6. CCR Subproject Requirements – technical requirements specific to the CCR
        subproject.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                     MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                        RFP OSI 7100-181
UIMOD PROJECT                                              SECTION 6C — PAGE 7 of 178




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.
Note: In the requirements the Unified Call Distribution (UCD) includes the functionality for
the call routing, the IVR functionality, and the skills-based routing.
See the following Appendices for reference:

   Appendix A, Skills-Based Routing
   Appendix B, Skills Definitions Matrix
   Appendix C, CCR Use Cases
   Appendix D, CCNPAU Use Cases
   Appendix G, CCNPAU Process Flow Diagrams




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                       MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
UIMOD PROJECT                                                      SECTION 6C — PAGE 8 of 178




6C.1.1        General Functional Requirements
                                                                                                          Bidder
Requirement
                                            Requirement                                       State Use   Agrees
Number
                                                                                                          (Y/N)
   1          The UCD must take information from callers to:                                  FCTN783
              a) Determine the caller‘s language.
              b) Determine whether the caller is seeking information or to file a
              claim.
              c) Determine the caller‘s Social Security Number.
              d) Determine the type of claim the caller should file:
                1) A regular California UI claim,
                2) A claim that seeks to combine wages with another state,
                3) A claim that is based on Federal employment, and
                4) A claim that is based on ex-Military employment.
              e) Route the call to the best agent, based on availability and skills
              required.
              f) Route the caller to the desired service with as few steps as
              possible.
              Note: The Employment Development Department (EDD) reserves
              the right to modify the list of information at system design time.
   2          The IVR must READ a listing of the documents and information that               FCTN784
              the caller must have available to file a claim, if the caller selects claim
              filing option.
              (See Appendix D - CCNPAU Use Cases for an explanation of Use
              Case terminology.)
   3          The UCD System must store information about each call, including,               FCTN861
              but not limited to, the Automatic Number Identification (ANI), the
              unique claimant ID # (which may be the Social Security Number
              (SSN)) if available, and the date and time of the call.
   4          The System must allow EDD to store phone numbers and identifying                FCTN863
              information that have been used to fraudulently file claims; i.e., tag
              data that indicates potential misrepresentation. This must be available
              for future enhancements to screen calls for potential fraud conditions
              and to automatically route suspect calls to a Customer Service
              Representative (CSR) during business hours.
   5          The System must provide the functionality from the UCD to the                   FCTN864
              ANI/SSN dataset to populate it with phone numbers (ANIs) that are
              frequently used to file claims.
   6          From any point in the System, the UCD must provide options for the              FCTN1207
              caller to navigate directly to another branch or the main menu.
   7          Based on claimant answers to questions, the UCD must route                      FCTN1208
              Overpayment calls to the location able to respond to the claimant's
              question or need.


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                    MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 9 of 178


                                                                                                      Bidder
Requirement
                                           Requirement                                    State Use   Agrees
Number
                                                                                                      (Y/N)
   8          The System must allow EDD staff to store phone numbers exempted             FCTN1218
              from checking for fraudulent or suspect activities (for example, the
              phone #s used in the Job Services offices). This will be used in future
              enhancements to screen calls for potential fraud conditions and to
              exempt calls from being automatically routed to a CSR.
   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         Web: The System must include a Content Management System with               FCTN895
              the capability 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 capability 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).
   21         The CCR subproject must use the IVR system as developed by the              FCTN1007
              CCNPAU subproject.
   22         The System must allow for the development of IVR scripts for all IVR        FCTN1008
              functionality.
   23         The IVR system must interface with the CCR System to update                 FCTN1010
              eligibility.
   24         The IVR system must allow Claimant to certify for benefits.                 FCTN1011
   25         The IVR system must allow Claimant to order forms.                          FCTN1012

0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 10 of 178


                                                                                                     Bidder
Requirement
                                            Requirement                                  State Use   Agrees
Number
                                                                                                     (Y/N)
   26         The IVR system must allow Claimant to check status of payment.             FCTN1013
   27         The IVR system must provide Claimant with payment amount.                  FCTN1014
   28         The IVR system must allow Claimant to change address.                      FCTN1015
   29         The IVR system must allow Claimant to change phone number(s).              FCTN1016
   30         The IVR system must allow Claimant to get list of appointments.            FCTN1017
   31         The IVR system must allow Claimant to cancel appointments.                 FCTN1018
   32         The UCD must take information from the caller to determine:                FCTN731
              a) The spoken language preference.
              b) Whether the caller is seeking information.
              If the caller is seeking information, the UCD system must route the
              call (using Skills-Based Routing) to either an agent or a prerecorded
              response to a question.
   33         If the caller is a claimant seeking claim information, the UCD system      FCTN732
              must verify the identity of the caller using an authentication system.
   34         For caller inquiries regarding payment status, the System must look–       FCTN733
              up:
               a) Date of last payment,
               b) Amount of last payment,
               c) Claim balance,
              and must SPEAK the results. (See Appendix D - CCNPAU Use
              Cases, Claimant: Inquiries about Payment Status.)




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                               MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
UIMOD PROJECT                                                     SECTION 6C — PAGE 11 of 178


                                                                                                            Bidder
Requirement
                                             Requirement                                        State Use   Agrees
Number
                                                                                                            (Y/N)
   35         The UCD must READ:                                                                FCTN734
              a) Explanations of selected forms in response to caller identification of the
              form in question. (See Appendix D - CCNPAU Use Cases, Claimant: How
              Do I Complete This Form? and Appendix D - CCNPAU Use Cases,
              Employer: How Do I Complete This Form?).
              b) The EDD UI Website address as an alternative means of obtaining
              information (See Appendix D - CCNPAU Use Cases, Claimant: How Do I
              complete This Form?).
              c) General information regarding the eligibility determination process (See
              Appendix D - CCNPAU Use Cases, Claimant: Inquiries about Determination
              Interviews).
              d) Directions to EDD offices based on ZIP code input from the caller (See
              Appendix D - CCNPAU Use Cases, Other: Out-System Referral).
              e) General information regarding appeals (See Appendix D - CCNPAU Use
              Cases, Claimant: Inquiries about Appeals).
              f) General information regarding the issuance of 1099G forms (See Appendix
              D - CCNPAU Use Cases, Claimant: Inquiries Regarding 1099G Forms).
              g) General information on the UI program in response to caller selection on a
              menu that includes, but is not limited to:
                1) Initial Claims:
                   A) Qualifying for benefits,
                   B) Claim filing Out-of-State,
                   C) Claim filing School employees, and
                   D) Military and Federal Claims.
                 2) Continued Claims:
                   A) Payments,
                   B) How do I certify for continued claims,
                   C) School attendance, and
                   D) Part-time work and wages.
                 3) Notice of Over Payment.
                 4) Appeals.
                 5) Fraud (include number for hot line).
                 6) Eligibility for Unemployment Insurance (See Appendix D - CCNPAU Use
              Cases, Other: Information on UI Processes).
                 7) General information regarding filing a fraudulent claim or providing
              fraudulent information.
               h) General information for employers includes, but is not limited to:
                1) Forms related to Unemployment Insurance,
                2) Notice of Wages,
                3) Notice of determination and/or ruling,
                4) Notice of claim filed,
                5) Response to Employer Communication,
                6) Notice of Benefit Audit,
                7) Employer Responsibilities (General),
                8) Appeals (See Appendix D - CCNPAU Use Cases, Other: Information on
              UI Processes), and
                 9) General information regarding filing a fraudulent claim or providing
              fraudulent information.
              i) General information regarding appeals (See Appendix D - CCNPAU Use
              Cases, Employer: Inquiries about Determinations and Appeals).




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                      MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                 RFP OSI 7100-181
UIMOD PROJECT                                                      SECTION 6C — PAGE 12 of 178


                                                                                                     Bidder
Requirement
                                            Requirement                                  State Use   Agrees
Number
                                                                                                     (Y/N)
   36         For inquiries regarding 1099Gs, the UCD system must:                       FCTN735
              a) Look-up the amount of the prior year's 1099 in the 1099 System
              and SPEAK the result to the caller.
              b) Allow the caller to request an additional copy.
              c) For a caller requiring an address change for the mailing of his or
              her 1099G, the UCD system must route the call to an address change
              voicemail box.
              d) Send an indicator to the 1099 system to send a new 1099G if
              requested (See Appendix D - CCNPAU Use Cases, Claimant:
              Inquiries Regarding 1099G Forms).
   37         The System must provide a file/data store that can be accessed by          FCTN859
              the UCD and maintained by EDD staff that will include:
              a) Name of Job Service office,
              b) ZIP codes served,
              c) Job Service office identifier, and
              d) Directions to the Job Service office (voice information).
   38         The System must provide the functionality that allows callers to enter     FCTN860
              a ZIP code and receive directions to the nearest EDD Job Service
              office.
   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.
              (See Appendix D - CCNPAU Use Cases, Claimant: Inquiries about
              Determination Interviews).
   40         The UCD must SPEAK information regarding the ID Alert process to           FCTN1206
              the caller in response to a request or based upon answers to
              questions.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                               MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 13 of 178



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 and web 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 IVR and web channels. Due to different technologies, initially the IVR 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)

Following are the functional requirements for continued claims (Certify for Benefits). The
initial release will contain a subset of these requirements.

                                                                                                     Bidder
Requirement
                                            Requirement                                  State Use   Agrees
Number
                                                                                                     (Y/N)
   41         The System must read a message to advise filing by another channel         FCTN740
              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 READ the ―false statement advice‖ and instructions.        FCTN742
   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.


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                               MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 14 of 178


                                                                                                         Bidder
Requirement
                                            Requirement                                      State Use   Agrees
Number
                                                                                                         (Y/N)
   46         The Contractor must implement the following continued claims                   FCTN745
              functionality in the IVR and web based system:
              a) The System must transfer information to SCDB using the Continued
              Claim Interface; i.e., send information regarding eligible weeks for
              benefits for which there are no issues.
              b) The System must be configured and implemented for
              Unemployment Insurance claimants to certify continued eligibility for
              benefits by telephone, the web or paper forms. Certifications without
              eligibility issues will be processed directly to payment without staff
              intervention.
              c) The System must route certifications with potential eligibility issues
              to work queues for resolution.
   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



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                   MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 15 of 178


                                                                                                       Bidder
Requirement
                                            Requirement                                    State Use   Agrees
Number
                                                                                                       (Y/N)
   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.
   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.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 16 of 178


                                                                                                   Bidder
Requirement
                                          Requirement                                  State Use   Agrees
Number
                                                                                                   (Y/N)
   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, Internet, 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.
   81         The System must route unscannable certifications to a work queue for     FCTN1285
              manual intervention.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                             MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                      RFP OSI 7100-181
UIMOD PROJECT                                           SECTION 6C — PAGE 17 of 178



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
    Internet.

6C.1.3.2      General CCR System Conditions

In addition to paper certification, Public Customers will access the CCR System via the
Internet 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.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                     MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 18 of 178



Employers will access the CCR System via the Internet or IVR to setup or manage Partial
and Work Sharing claims.
Program Analysts will access the CCR System via an internal network connection to
generate fraud reports, publish content to the Internet, or process Web correspondence
(correspondence received via the Internet).
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 Internet 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 Internet.
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 login and access capability.                        FCTN907
   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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 19 of 178


                                                                                                      Bidder
Requirement
                                           Requirement                                    State Use   Agrees
Number
                                                                                                      (Y/N)
   89         If the user is shut out, the System must notify the Claimant of the         FCTN911
              course of action to take.
   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.
   92         The System must allow the Claimant to download claim specific               FCTN914
              forms.
   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 capability to allow or restrict a claimant's       FCTN1292
              access to any certification channel.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 20 of 178



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.

0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 21 of 178


                                                                                                    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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                              MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 22 of 178



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        The system must authenticate the user and allow the user to request        FCTN1315
              the User ID be sent via the USPS or e-mail.



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.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                               MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 23 of 178


                                                                                                      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




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 24 of 178



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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 25 of 178


                                                                                                      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




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 26 of 178



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 provide the capability to generate a temporary one-       FCTN1061
              time password and send it to 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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                              MARCH 23, 2007
 OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
 UIMOD PROJECT                                                     SECTION 6C — PAGE 27 of 178


                                                                                                       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.




 0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 28 of 178



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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                   MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 29 of 178



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).


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                              MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 30 of 178


                                                                                                   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).


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                             MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 31 of 178




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.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                               MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                 RFP OSI 7100-181
UIMOD PROJECT                                                      SECTION 6C — PAGE 32 of 178


                                                                                                            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.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                      MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 33 of 178


                                                                                                  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 capability to identify the data that is     FCTN1167
              most predictive of fraud patterns.


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                            MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 34 of 178


                                                                                                        Bidder
Requirement
                                            Requirement                                     State Use   Agrees
Number
                                                                                                        (Y/N)
   292        The System must provide the capability to monitor the information in          FCTN1168
              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 capability to          FCTN1170
              document potential fraud.
   295        The System must provide the Fraud Analyst with on-line capability to          FCTN1171
              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 Internet.

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




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 35 of 178



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

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
              Internet.
   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




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 36 of 178



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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                               MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                        RFP OSI 7100-181
UIMOD PROJECT                                             SECTION 6C — PAGE 37 of 178



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 UCD 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 (Internet, 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).




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                        MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 38 of 178




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.
                                An Internet-based customer service tool that allows customers to access
EDDCOMM                         answers to 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.


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                        RFP OSI 7100-181
UIMOD PROJECT                                             SECTION 6C — PAGE 39 of 178



      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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                         MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 40 of 178



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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 41 of 178




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        UCD Interfaces must be maintainable through commercially available             IFACE7
              tools.
   330        All UCD 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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 42 of 178


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




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                            MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 43 of 178



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 Internet
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




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                             MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 44 of 178



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 Internet
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
                the last calendar year.
    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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                               MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                       RFP OSI 7100-181
UIMOD PROJECT                                            SECTION 6C — PAGE 45 of 178



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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                       MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 46 of 178



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
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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                             MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 47 of 178



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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                               MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 48 of 178



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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                              MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 49 of 178




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 Internet
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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                             MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 50 of 178



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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                              MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                          RFP OSI 7100-181
UIMOD PROJECT                                               SECTION 6C — PAGE 51 of 178



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




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                             MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 52 of 178



            Information Category                                         Description
Assumed Integration Interface               CA‘s IDMS SQL bridge with ODBC drivers for access to the
                                            databases, and/or by direct access to the application transaction
                                            log.
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           CA‘s IDMS SQL bridge requires developing a meta data mapping
Service Provider Application                table(s) and associated procedures.
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.


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                               MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                         RFP OSI 7100-181
UIMOD PROJECT                                              SECTION 6C — PAGE 53 of 178


                                                                                                  Bidder
Requirement
                                        Requirement                                  State Use    Agrees
Number
                                                                                                  (Y/N)
    367         The System must communicate CCR System Update Claim Change           IFACE58
                requests via message queue or batch.



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          CA‘s IDMS SQL bridge with ODBC drivers for access to the
                                       databases
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      CA‘s IDMS SQL bridge requires developing a meta data mapping
Service Provider Application           table(s) and associated procedures.
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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                          MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                     RFP OSI 7100-181
UIMOD PROJECT                                          SECTION 6C — PAGE 54 of 178



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 10000         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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                      MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 55 of 178



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             CA‘s IDMS SQL bridge with ODBC drivers for access to the
                                          databases


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                             MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 56 of 178



          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            CA‘s IDMS SQL bridge requires developing a meta data mapping
Service Provider Application                 table(s) and associated procedures.
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).




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
UIMOD PROJECT                                                     SECTION 6C — PAGE 57 of 178



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                CA's IDMS SQL bridge with ODBC driver for access
Interface Complexity                         Moderate
Programming Required on Legacy or            CA‘s IDMS SQL bridge requires developing a meta data mapping
Service Provider Application                 table(s) and associated procedures.
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

0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                       RFP OSI 7100-181
UIMOD PROJECT                                            SECTION 6C — PAGE 58 of 178


                                                                                             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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                       MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                         RFP OSI 7100-181
UIMOD PROJECT                                              SECTION 6C — PAGE 59 of 178



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          CA's IDMS SQL bridge with ODBC driver for access


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                          MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 60 of 178



          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        CA‘s IDMS SQL bridge requires developing a meta data mapping
Service Provider Application             table(s) and associated procedures.
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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                              MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 61 of 178



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               CA's IDMS SQL bridge with ODBC driver for access
Interface Complexity                        Complex
Programming Required on Legacy or           CA‘s IDMS SQL bridge requires developing a meta data mapping
Service Provider Application                table(s) and associated procedures.
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 Check         IFACE77
               Messaging             for Overpayment transactions at peak hour.
               Volume
   387         Communication         The System must communicate Check for                  IFACE78
               Style                 Overpayment requests via message queue.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
UIMOD PROJECT                                                     SECTION 6C — PAGE 62 of 178




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                CA's IDMS SQL bridge with ODBC driver for access
Interface Complexity                         Complex
Programming Required on Legacy or            CA‘s IDMS SQL bridge requires developing a meta data mapping
Service Provider Application                 table(s) and associated procedures.
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 Needs      The System must utilize benefit accounting           IFACE79
                                      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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 63 of 178



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.

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              CA's IDMS SQL bridge with ODBC driver for access
Interface Complexity                       Moderate
Programming Required on Legacy or          CA‘s IDMS SQL bridge requires developing a meta data mapping
Service Provider Application               table(s) and associated procedures.
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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                             MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 64 of 178



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




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                              MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 65 of 178


                                                                                                    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.


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.

0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                              MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 66 of 178


                                                                                                     Bidder
Requirement
                Context                              Requirement                         State Use   Agrees
Number
                                                                                                     (Y/N)
    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.



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             CA's IDMS SQL Bridge with ODBC driver for access.
Interface Complexity                      Simple
Data Transformation                       None
Programming Required on Legacy or         CA‘s IDMS SQL bridge requires developing a meta data mapping
Service Provider Application              table(s) and associated procedures.
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.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                               MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                       RFP OSI 7100-181
UIMOD PROJECT                                            SECTION 6C — PAGE 67 of 178


                                                                                              Bidder
Requirement
              Context                           Requirement                       State Use   Agrees
Number
                                                                                              (Y/N)
   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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                        MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 68 of 178



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
Programming Required on Legacy or      None
Service Provider Application



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                         MARCH 23, 2007
 OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
 UIMOD PROJECT                                                    SECTION 6C — PAGE 69 of 178



           Information Category                                            Description
 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        Peak Hour          The System must update Check Warrant                      IFACE89
                Messaging          information during daily batches.
                Volume
     411        Communication      The System must communicate through secure                IFACE90
                Style              (encrypted) FTP for any interface that requires files
                                   be sent via FTP file transfer.



 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 Internet
 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

 0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 70 of 178



          Information Category                                          Description
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.


6C.2.3.11.7         ODPD Notification Interface – Interface Requirements
                                                                                                        Bidder
Requirement
                Context                               Requirement                         State Use     Agrees
Number
                                                                                                        (Y/N)
    412        Integration Needs   The System must integrate and use ODPD for all         IFACE103
                                   notification via USPS.
    413        Daily Volume        The System must support a minimum of:                  IFACE104
               /Load
                                   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:
               Volume
                                   a) 784 Employer Notifications (DE1101CZ),
                                   b) 185 DE1080CSI Notifications 784
                                   DE1101CLMT Notifications,
                                   c) 12,869 DE4581s (no warrant attached),
                                   d) 5,422 Message stubs (no warrant attached),
                                   e) 26,000 Warrants (majority have 4581s
                                   attached, all have message stubs),
                                   f) 10 DE8784s, and/or
                                   g) 40 DE731s.
    415        Communication       The System must communicate ODPD                       IFACE106
               Style               Notification Interface requests via FTP.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                              MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 71 of 178



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.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 72 of 178


                                                                                                      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.



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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                              MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                         RFP OSI 7100-181
UIMOD PROJECT                                              SECTION 6C — PAGE 73 of 178



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).
   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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                           MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                          RFP OSI 7100-181
UIMOD PROJECT                                               SECTION 6C — PAGE 74 of 178



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       The System must be accessible via the EDDCOMM     IFACE130
               Needs             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 peak
               Volume            hour.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                         MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 75 of 178



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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 76 of 178


                                                                                                         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.


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.


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
UIMOD PROJECT                                                     SECTION 6C — PAGE 77 of 178


                                                                                                         Bidder
Requirement
                Context                                 Requirement                          State Use   Agrees
Number
                                                                                                         (Y/N)
   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.

6C.2.3.16            Port Usage Billing Requirements
                                                                                                         Bidder
Requirement
                                              Requirement                                    State Use   Agrees
Number
                                                                                                         (Y/N)
   435        Contractor must certify that any IVR ports, whether dedicated to EDD or
              not, must be billable to EDD for port usage only rather than for capacity.     SUPP81
              The EDD will pay for ports used only, not for ports available.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                   MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 78 of 178



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




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                             MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                       RFP OSI 7100-181
UIMOD PROJECT                                            SECTION 6C — PAGE 79 of 178



6C.4          REPORTING / BUSINESS INTELLIGENCE REPORTING
              REQUIREMENTS
Business intelligence and reporting requirements include general requirements as well as
requirements for data warehouse models, data warehouse management tools, Extraction,
Transformation and Loading (ETL) tools, data mining, reporting tools and reports.
The EDD requires standardized reports and ad hoc reporting that will facilitate good
management of the UCD and the UI program.
The UCD must include an operational reporting engine that will be used for standardized
and ad hoc reporting on activities that occur within the UCD system.
In addition, both the UCD system and the CCR System must include a facility for exporting
information to an external, common "UI Data Warehouse".




    Figure 6C.1 Operational Reporting and Business Intelligence Environment

Contractors must provide evidence of their ability to produce, at a minimum, reports
equivalent to those produced today by the current System (sample reports can be found in
the Bidders' Library). 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, while the


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                     MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                       RFP OSI 7100-181
UIMOD PROJECT                                            SECTION 6C — PAGE 80 of 178



actual creation of the report when the new UCD is implemented may not be available at
UCD system implementation, depending on the Contractor‘s proposal.
Some reports listed will require information from a source other than the UCD and the CCR
System. Data from all required sources will be combined and managed in a centralized data
warehouse and available for usage by the UI program.
Mandatory Qualifications for the reporting requirements are presented below. 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.

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.

0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                   MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 81 of 178



     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.
     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        The UCD must have the capability to export data to an external data     FCTN747
              warehouse.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                            MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 82 of 178


                                                                                                        Bidder
Requirement
                                             Requirement                                    State Use   Agrees
Number
                                                                                                        (Y/N)
   443        The UCD must provide reports in a ―real-time‖ window with ―point-in-          FCTN755
              time‖ information no more than 10 seconds old, as low as 5 minute
              rolling increments, and available over 24 hours.
   444        User must have the ability to define the ―time-slices‖ for reports in the     FCTN756
              real-time window.
   445        The UCD reporting system must have the capability to summarize, as            FCTN802
              well as ―drill down‖, to view enterprise data at individual levels.
   446        The UCD reporting system must provide self-training modules for lead          FCTN804
              workers and managers to develop reports.
   447        The UCD reporting system must provide secure, remote monitoring               FCTN807
              and administration from locations other than the call center.
   448        The UCD must include a reporting engine that will be used for both            FCTN871
              standardized and ad hoc reporting on activities that occur within the
              UCD system.
   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.
   452        The CCR System must provide for secure data extraction using                  FCTN1305
              authentication & 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 (e.g. SAS). EDD is currently
              evaluating data mining tools; the tool will be specified by EDD at time
              of implementation.
   453        The Contractor must construct the UCD such that all data collected            SUPP80
              from the caller and all data regarding the call (ANI, duration, menu
              options selected, etc.) can be exported into the UI Data Warehouse.

   454        The Data Warehouse must include administration tools that support             SUPP604
              data usage auditing.

   455        The Data Warehouse must include administration tools that support             SUPP605
              business information and model maintenance.

   456        The Data Warehouse must include administration tools that support             SUPP606
              security control (authentication and access management).

   457        The Data Warehouse must include administration tools that support             SUPP608
              query cataloging.

   458        The Data Warehouse must include administration tools that support             SUPP609
              creating, updating, and deleting data extracts from the production
              environment into the Data Warehouse.

   459        The Data Warehouse must include administration tools that support             SUPP610
              backups.

   460        The Contractor must implement instrumentation and tools to monitor            SUPP611
              query performance.

0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 83 of 178


                                                                                                      Bidder
Requirement
                                              Requirement                                 State Use   Agrees
Number
                                                                                                      (Y/N)
   461        The CCR System must include Extration, Transformation and Loading           SUPP612
              (ETL) tools in support of acquisition of data from all target systems.

   462        The ETL tools must support the movement of data for both real time          SUPP613
              and batch-oriented data integration processes that will feed data
              warehouses or data marts.

   463        The ETL tool must support complex logic for transformation of data          SUPP614
              into the proposed data warehouse models and formats.

   464        The ETL tools must support development of custom adapters and               SUPP615
              transformation rules using standard XSL, XML, and .NET Framework.

   465        The CCR System must support incremental loading of data into the            SUPP616
              Data Warehouse based on changes to the CCR System and other
              databases.

   466        The CCR System must include a standardized Web-based reporting              SUPP618
              tool to allow authorized users to access standardized reports, and to
              create and publish ad-hoc reports, over the Web.

   467        For end-user, ad-hoc reporting needs, the Prime Contractor must             SUPP644
              deliver solutions based on Microsoft Reporting Services, or the
              equivalent product from Microsoft that is available at the time of
              contract award.

   468        The Data Warehouse must include administration tools that support           SUPP652
              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        The Data Warehouse must include administration tools that allow the         SUPP654
              publishing of new reports, and in such a way that only authorized
              users are allowed access.

   470        The reporting system (including the UCD Reporting System and any            SUPP849
              Data Warehouse Reporting capabilities) must provide the capability to
              restrict access to reports, data or other reporting resources according
              to the authorization level assigned to the requestor.

   471        The Contractor shall ensure that construction and usage of the              SUPP853
              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.



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




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 84 of 178



6C.4.6        Business Intelligence and Reporting: Constraining Requirements
                                                                                                      Bidder
Requirement
                                             Requirement                                  State Use   Agrees
Number
                                                                                                      (Y/N)
   472        The UCD must include a reporting system that will provide information       FCTN746
              on call process activity.
   473        The System must have the capability to support at least 100                 FCTN748
              concurrent users. This includes, but is not limited to, real time
              monitoring and running of historical reports.
   474        The System must collect information and monitor the use of UCD              FCTN749
              system components (e.g., routers, switches, lines) and provide reports
              on System status.
   475        Data Quality: UCD data must:                                                FCTN757
              a) be accurate.
              b) be timely.
              c) not be corrupt.
              d) not be expired.
              e) meet data quality standards of EDD, (See the Bidders' Library).
              f) represent what it purports to represent.
   476        Reports must be accessible from any management workstation in any           FCTN873
              location.
   477        The System must retain at least three (3) years of data beginning with      FCTN1215
              the start up of the first call center.
   478        The System must make the most recent three (3) years of continued           FCTN1302
              claims archive retrieval functionality for ad-hoc data reporting.
   479        The System must have the capability to save summarized information          FCTN1303
              for a configurable period of time, and make this summary information
              available in the business intelligence reporting environment.
   480        For the UCD system, any increase in the number of reports run, or in        SUPP16
              the execution time of existing reports, must be isolated from, and have
              no impact on, the production environment.
   481        The CCR System must include a business intelligence and reporting           SUPP600
              environment that is separate from the production environment to
              support business reporting.
   482        The data models in the data warehouse must be structured for                SUPP603
              reusability.
   483        Claimant related data in the Data Warehouse must be refreshed daily,        SUPP617
              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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 85 of 178



The UIMOD Project introduces a comprehensive Data Warehouse into the EDD
environment. Requirements for the capabilities of this new end-user reporting environment
are described below.

6C.4.7        Business Intelligence and Reporting: Ad-hoc Reporting
              Requirements
                                                                                                        Bidder
Requirement
                                             Requirement                                    State Use   Agrees
Number
                                                                                                        (Y/N)
   485        The System must report on everything that an agent and caller do in           FCTN750
              the UCD.
   486        The UCD reporting system must provide the following reporting                 FCTN799
              capabilities:
              a) Ability of UCD system to summarize data,
              b) Ease-of-use by non-technical staff,
              c) Inclusion of a self-training module for developing new reports,
              d) Flexibility to change/revise reports,
              e) Easily downloadable to Microsoft Excel, and
              f) Easily reports on different time periods (days, weeks, months,
              quarters, fiscal years, etc.).
   487        The UCD reporting system must provide information on performance              FCTN800
              and training, formatted by enterprise, organizational entity, skill sets,
              and agents.
   488        The UCD reporting system must report scheduling information – days            FCTN801
              and hours.
   489        The UCD reporting system must have the capability to report on                FCTN803
              different time periods (days, weeks, months, quarters, fiscal years,
              etc.).
   490        The UCD reporting system must provide a reporting capability that             FCTN810
              reflects the activity of a single caller.
   491        The UCD reporting system must provide the capability to set UCD               FCTN819
              system reporting parameters so that data such as ―calls abandoned‖
              can be reported in increments from a minimum of 10 second intervals
              to a total time of 30 minutes.
   492        The UCD reporting system must provide a report using ANI as a                 FCTN821
              measure of customer demand so that duplicate ANIs can be
              calculated as an indication of the total number of unique ANIs.
   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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 86 of 178


                                                                                                        Bidder
Requirement
                                            Requirement                                     State Use   Agrees
Number
                                                                                                        (Y/N)
   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.)
   497        The Contractor must use current industry recognized tools to build,           SUPP17
              test, and deploy new UCD/IVR reports.
   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, an by other
              demographic parameters).



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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
UIMOD PROJECT                                                     SECTION 6C — PAGE 87 of 178


                                                                                                        Bidder
Requirement
                                               Requirement                                  State Use   Agrees
Number
                                                                                                        (Y/N)
   501        The System must report on the following data and statistics, sorted by        FCTN753
              individual and by time frame:
              a) Total calls per agent (to the half-hour),
              b) Average and maximum call handle time per agent (length of time on
              phone with customer); longest call; by skill type and call type (to ½
              hour),
              c) Walk-away codes by function—for non-phone work (to ½ hour),
              d) Transfers (anytime call taken and transferred) (to ½ hour),
              e) Talk time—average and total per agent,
              f) Number of short calls,
              g) Amount of time a person is on second line,
              h) Calls going out,
              i) Longest call in queue,
              j) Average call time in queue,
              k) Average wait time,
              l) Length of calls (longest time, average time),
              m) Status of agents (on a live call, separate duty, etc.),
              n) Number of claims filed today and calls taken,
              o) Claim, information, questions, and certifying for benefits activities,
              p) Volume of calls and different time slices (rolling time period) – how
              many have come in, how many have been answered,
              q) Deflects and abandons - ACD or local situation,
              r) Status on outbound calls (on primary and secondary lines) including
              talk time, hold time, number of calls, and average length of calls,
              s) Status on inbound calls (on primary and secondary lines) including
              talk time, hold time, number of calls, and average length of calls,
              t) Transfers on inbound and outbound, and
              u) Percentage of wait time and talk time.
   502        The System must report on the following process data and statistics:          FCTN754
              a) Type of calls by language,
              b) Length of calls, longest call in each queue,
              c) Number of calls waiting in each queue,
              d) Number of available agents in each queue,
              e) Number of unavailable agents in each queue, and
              f) Numbers of abandons at menu location and average length of time.
   503        The UCD reporting system must report on number of calls taken by              FCTN790
              agent.


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                 RFP OSI 7100-181
UIMOD PROJECT                                                      SECTION 6C — PAGE 88 of 178


                                                                                                      Bidder
Requirement
                                              Requirement                                 State Use   Agrees
Number
                                                                                                      (Y/N)
   504        The UCD reporting system must report on short calls.                        FCTN791
   505        The UCD reporting system must report on walk-away times.                    FCTN792
   506        The UCD reporting system must count the number of 800 number                FCTN793
              calls that are blocked due to UCD system error or sent to a busy
              message due to capacity limitations, separately, at initial entry point
              and when trying to go from the IVR to a queue or agent so the cause
              of the blockage is known.
   507        The UCD reporting system must report on the following data and              FCTN794
              statistics, sorted by organizational entity, unit, individual, and time
              frame:
              a) Total calls by function (business activity code),
              b) Walk-away times,
              c) Short calls,
              d) Average talk time, handle time, and
              e) Path of individual call (e.g., who took the call, etc.).
   508        The UCD reporting system must report on agent activity based upon           FCTN795
              business functionality (business codes) for work performed.
   509        The UCD reporting system must provide the ability for agents to enter       FCTN796
              an activity code that describes current work.
   510        The UCD reporting system must report use/allocation of staff within a       FCTN797
              call center, based upon call data.
   511        The UCD reporting system must report on long-term information for           FCTN798
              trend analysis – time-sliced, language-sliced, program-sliced:
              a) Number of calls coming in,
              b) Length of calls,
              c) Number of claims filed,
              d) Number of certifications, and
              e) Information on determinations and other types of outbound calls.
   512        The UCD reporting system must provide personnel reports by half             FCTN808
              hour, day, week, month, quarter, and year.
   513        The UCD reporting system must provide a daily report, including             FCTN809
              percentage usage by port, percentage usage by menu item, and
              attempts by individual 800 number (how many completed, how many
              were not completed, total minutes).
   514        The UCD reporting system must provide reports on resource                   FCTN811
              management (i.e., port utilization, trunk usage, etc.).
   515        The UCD reporting system must provide exception reporting; i.e.,            FCTN812
              reports regarding data that could not be written to interfaced system.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 89 of 178


                                                                                                       Bidder
Requirement
                                            Requirement                                    State Use   Agrees
Number
                                                                                                       (Y/N)
   516        The UCD reporting system must provide reporting on both routine and          FCTN813
              unscheduled maintenance. ―Routine maintenance‖ refers to
              maintenance that is scheduled and conducted on a regular, periodic
              basis as contractually required by purchase contract. ―Unscheduled
              maintenance‖ refers to maintenance which is not routine. Reporting
              on both routine and unscheduled maintenance should provide, at a
              minimum:
              a) Date and time of maintenance.
              b) Reason for maintenance.
              c) If not routine maintenance, then a detailed description of problem
              reported and addressed.
              d) Specific systems and system components that were subject(s) of
              the maintenance.
              e) Specific results/outcomes of the maintenance (if maintenance is
              routine, outcome may be that ―system is operating normally with no
              modifications required‖).
   517        The UCD reporting system must provide reporting on equipment level           FCTN814
              and version status of systems and systems components, including
              identification of version levels of all software and software ―patches.‖
   518        The UCD reporting system must provide system administration reports          FCTN815
              (user id management, virus definitions, service packs, performance,
              etc.).
   519        The UCD reporting system must provide an ANI report that calculates          FCTN818
              the number of calls per ANI and then populate the ―hot list‖ based on
              an established threshold.
   520        The UCD reporting system must provide a report comparing outcomes            FCTN820
              by call center and identification of differences.
   521        The UCD reporting system must provide a report of historical UCD             FCTN822
              data and claims information that can be used for projecting staffing
              needs.
   522        The UCD reporting system must provide the capability to count the            FCTN824
              number of 800 number calls that are blocked due to UCD system error
              or sent to a busy message due to capacity limitations, separately, at
              initial entry point and when trying to go from the IVR to a queue or
              agent so the cause of the blockage is known.
   523        Reports must be available in batch mode as scheduled reports.                FCTN870
   524        The System must be able to produce the information for mandated              FCTN1142
              Federal and State reports. (See the Bidders' Library for list of Federal
              and State reports.)
   525        The System must provide a dashboard capability to allow managers to          FCTN1145
              have 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.).



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 90 of 178


                                                                                                          Bidder
Requirement
                                             Requirement                                      State Use   Agrees
Number
                                                                                                          (Y/N)
   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 (Internet 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



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        All UCD data elements must be fully defined in a narrative format.              FCTN758




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                    MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
UIMOD PROJECT                                                     SECTION 6C — PAGE 91 of 178


                                                                                                       Bidder
Requirement
                                             Requirement                                   State Use   Agrees
Number
                                                                                                       (Y/N)
   533        The UCD reporting system must report on the following data and               FCTN806
              statistics, sorted by individual and by time frame:
              a) By skill set, call type, call center, and enterprise.
              b) Number of agents talking.
              c) Calls in queue.
              d) Average speed of answer.
              e) Average and maximum answer delay.
              f) Average and maximum talk time.
              g) Average and maximum abandon delay.
              h) Average and maximum delay before abandonment.
              i) Number of blocked calls.
              j) Queues by organizational entity, by skills.
              k)Status of agents (on a live call, separate duty, etc.).
              l) Service levels.
              m) Claim activity, and information and questions activity.
              n) Volume of calls and different time slices (rolling time period) – how
              many have come in, how many have been answered.
              o) Deflects and abandons.
              p) Number of attempts, number of busies, and blocked calls.
              q) Status of servers (including UCD), lines, numbers (problem
              displays, alarms, etc.).
   534        The UCD reporting system must provide journal entry reporting for all        FCTN816
              UCD system changes by the User ID of the person making the
              change (Contractor and EDD).
   535        The UCD reporting system must provide the ability to define day as           FCTN817
              something other than a 24 hour period; in particular, ability to define
              day as 8:00 – 5:00.
   536        The UCD reporting system must provide the capability to perform ad           FCTN825
              hoc queries. All data elements used or needed to create the various
              reports must be accessible for use even though they may not be
              included in a standard report template.
   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.


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 92 of 178


                                                                                                        Bidder
Requirement
                                            Requirement                                     State Use   Agrees
Number
                                                                                                        (Y/N)
   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 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.
   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        The System must produce a report providing the number of                      FCTN843
              certifications filed from same ANI number.
   553        The System must produce a report providing the number of attempted            FCTN844
              certifications filed from same ANI number.
   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
              NAICS, education, last employer, zip code, race, VLI, time/date
              certification filed, and other demographic information, as needed.
   556        The System must produce a report providing the number of agent-               FCTN847
              assisted certifications (by call center and agent ID).
   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        The System must be able to produce the information to report on               FCTN1148
              phone calls from the same ANI and the path of the call in the IVR.
   559        The System must be able to produce the information to report on               FCTN1149
              continued claims transaction volumes.


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 93 of 178


                                                                                                    Bidder
Requirement
                                          Requirement                                   State Use   Agrees
Number
                                                                                                    (Y/N)
   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 UCD reporting system must use one data element for every              SUPP18
              function. Each data element will be unique and always appear the
              same when reported.
   568        The Contractor must develop and implement all critical interfaces to      SUPP601
              extract data from the various operational systems and import the data
              to the CCR System Data Warehouse.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                              MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                   RFP OSI 7100-181
UIMOD PROJECT                                        SECTION 6C — PAGE 94 of 178




6C.5 CCNPAU REQUIREMENTS

6C.5.1       Equipment

   All current equipment, except desktop phone instruments, headsets, wallboards, and
   the MIS system, is leased. All equipment will be replaced in this engagement.

   1. Wiring at the Call Center level is installed at the CAT 5 or CAT 6 level and
      attaches to equipment through patch panels in a data closet. This is adequate to
      support any new equipment needed to support the UCD. Any new wiring should
      be at the CAT 6 level.

6C.5.2       Network

   1. The Department of Technology Services (DTS) network is currently
      reconstructing the LATA/HUB system for State government in California. It is
      assumed that this Project will be completed before UI Modernization
      implementation.

   2. California is currently rebidding the CalNet contract for phone services. The new
      contract is expected to be awarded in October 2006. It is assumed that EDD will
      develop an interim agreement for support of its current system between the time
      that CalNet 2 is put in place and that the UI Modernization Project will use its
      platform.


6C.5.3       Major System Constraints

   1. Data and Voice Network: The EDD utilizes the State‘s voice and data network
      via the CalNet contract. The Department of General Services (DGS) gave EDD
      delegation approval for this project.

   2. Batch Processing Window: The SCDB has a batch processing window that
      starts at 6:00 p.m. each night and ends at 5:00 a.m. the following morning.
      During this time, the main processing system for the UI program is not available
      for real-time input. Any system that collects data during SCDB batch processing
      hours must cache data.

   3. Replacement of Leased Equipment: Current network and voice processing
      equipment in Call Centers is leased and must be replaced as a part of the
      CCNPAU engagement.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 95 of 178



    4. Replacement of EDD-Owned Equipment: Current telephone sets and headsets
       are EDD-owned equipment and must be replaced as a part of the CCNPAU
       engagement. Wallboards are also EDD-owned. Wallboards or another solution
       proposed by the contractor with the same functionality will also be replaced.


6C.5.4              System Availability
The UCD system will be capable of redundant 24x7 operation, except as may be required
for scheduled maintenance. The Department expects that scheduled maintenance be
completed during slow periods, when it would be least disruptive for the business and
service delivery. The UI business model calls for less claim certification activity on Saturdays
because there is no UI payment process on Saturday night and the claim week starts on
Sundays. The UCD has two (2) modes: active and inactive. The table below shows when
the UCD is in active or inactive state.

                Table 6C.1 System Modes and States at Initial Implementation
    Function            State              Time Frame                              Activity
Claim                  Active     24 x 7                   Receive Continued Claim Certifications from UI
Certification for                                          claimants.
                                  (Except for scheduled
Benefits
                                  maintenance)
Claim                  Inactive   As required per          Scheduled maintenance (Schedule to be
Certification                     maintenance schedule     determined and approved by EDD)
Claim Filing           Active     Monday – Friday          Receive callers who wish to file claims. The IVR
                                                           must be able to route calls to an ―Office Not Open‖
                                  6:30 a.m. to 6:00 p.m.
                                                           message if the call is outside of normal business
                                                           hours, currently 8:00 a.m. to 5:00 p.m. The EDD
                                                           must be able to extend business hours to
                                                           6:30 a.m. – 6:00 p.m.
Claim Filing           Inactive   Weekends, Evenings       Common maintenance window with Claim
                                                           Certification.
                                  6:01 p.m. to 6:29 a.m.
UI Information         Active     24 x 7 (Except for       Available for general information calls that do not
                                  scheduled maintenance)   require staff involvement (prerecorded answers to
                                                           questions)
UI Information         Inactive   As required per          Scheduled maintenance (Schedule to be
                                  maintenance schedule     determined and approved by EDD)




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                              MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 96 of 178



EDD requires that availability be at a 99.9 percent level during the times when the UCD is
active.

The EDD must have the ability to shift the Active and Inactive hours at will, so that changes
to the UCD can be made to correspond to any changes in the maintenance periods.

6C.5.4.1      System Availability Requirements
                                                                                                         Bidder
Requirement
                                             Requirement                                     State Use   Agrees
Number
                                                                                                         (Y/N)
   569        Contractor must design and implement a UCD system that will be                  SUPP2
              available 99.9 percent of the time that it is scheduled to be active.
              This requirement applies to the availability of the UCD, but not
              necessarily in all Centers. In case of UCD system failure in one Call
              Center, the UCD will reroute calls to operational Centers in a fail-over
              mode.
   570        The UCD must recognize a UCD system failure in any location, inform             SUPP3
              support staff and the Contractor of the failure, reroute calls to the
              remaining active call centers, and route the calls back to the failed call
              center after service is restored.
   571        In case of a partial UCD system failure in the Skills-Based Routing             SUPP4
              Module, the UCD must provide a ―default routing table‖ that will allow
              the UI program to continue to operate.
   572        The installed UCD must be geographically distributed so that failure in         SUPP5
              a single location will not result in failure of the entire UCD system.
   573        The UCD system must provide configuration management (version                   SUPP6
              control and backup and recovery) controls to restore the hardware,
              software and data in the event of UCD system failure or disaster.
              Redundant equipment must be located in a geographical location
              approved by the EDD to ensure environmental stability (e.g., not in
              same flood plain or earthquake zone as primary equipment).



6C.5.5        System Capacity

   1. There will be 2,083 seats in the Multi-Function Centers (which includes the
      current Primary Adjudication Centers (PACs) and the Insurance Accounting
      Division). Those seats shall be filled during the seasonal maximum workload
      and during economic down-cycle (peak volume).
   2. Of the 2,083 seats available at peak volume, approximately 75 percent will be
      using the UCD system and actually be on the telephone at any one time.
      Therefore, the peak capacity users of the UCD system telephones are 1,566.
   3. The number of trunks required for UCD system capacity, at a minimum, must
      support one caller waiting in queue for every two (2) agents logged on to the
      UCD.

0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                   MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                  RFP OSI 7100-181
UIMOD PROJECT                                                       SECTION 6C — PAGE 97 of 178



   4. For calculating peak capacity of the UCD system, it is assumed that peak load for
      Continued Claim Certification will occur on a Sunday and that peak load for
      Claim Filing and UI Information will occur on the following Monday.


6C.5.5.1        System Capacity Requirements
                                                                                                                 Bidder
Requirement
                                              Requirement                                          State Use     Agrees
Number
                                                                                                                 (Y/N)
   574         The UCD system must have the capacity to handle calls at the peak                   SUPP7
               hour levels described in Appendix E - Peak Volume Estimator.
   575         The Contractor must propose a UCD system with dynamic capacity                      SUPP8
               allocation; i.e., for in-coming calls, capacity will be allocated so that
               there is little to no excess capacity and EDD will pay for only the
               capacity that is used.
   576         The UCD system must support distribution of calls at a peak hour level              SUPP9
               to the 15 call centers as shown in Appendix E - Peak Volume
               Estimator.
               a) The UCD system must provide an anticipated wait message for all
               calls queued. If the anticipated wait time exceeds 10 minutes, then
               the UCD system must play a custom message in the network to advise
               callers all agents are busy and to try again later. The EDD must be
               able to update these messages at will.
               b) The UCD must refer callers to a custom busy message that the
               EDD has the ability to update if a UCD system issue or capacity issue
               is encountered that prevents the caller from reaching the IVR on the
               first attempt.



The EDD will be reengineering its working environment so that current Primary Call Centers
(PCCs) and Primary Adjudication Centers (PACs) can perform all UI functions; i.e., all
offices will become Multi-Function Centers.

                                Table 6C.2 Staffing and Phones
                              Agent       Design       Training       Supervisor           Total ACD
         Location                                                                                              Analog
                              Seats      Capacity       Seats           Seats                Seats
Oakland PCC                    229          172           27               23                279                27
San Jose PAC                   146          110           10               15                171                29
San Francisco PAC              130           98           19               13                162                23
Sacramento PCC                 119           89           11               12                142                23
Sacramento PAC                 132           99           20               13                165                23
Rancho Cordova IAD              74           56            0               7                  81                20
Los Angeles PCC                179          134           32               18                229                46
Los Angeles PAC                155          116           15               16                186                29


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                     MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 98 of 178



                            Agent       Design     Training      Supervisor         Total ACD
         Location                                                                                     Analog
                            Seats      Capacity     Seats          Seats              Seats
San Bernardino PAC            114         86          21             11                146             22
Riverside PCC                 110         83          20             11                141             22
Inglewood PAC                 120         90          22             12                154             23
Orange County PAC             154         116         18             15                187             29
Orange County PCC             157         118         30             16                203             29
San Diego PAC                 102         77           9             10                121             22
San Diego PCC                 162         122         20             16                198             20
Totals                       2083        1566         274            208               2565            387


6C.5.6          Enterprise UCD Requirements
                                                                                                        Bidder
Requirement
                                            Requirement                                   State Use     Agrees
Number
                                                                                                        (Y/N)
   577          As an enterprise system, the UCD must be expandable, scalable, and        SUPP10
                upgradeable without the need to replace or substantially upgrade the
                installed UCD system. Upgrades apply to both capacity and
                functionality.
   578          The Contractor must install uniform equipment in support of the UCD       SUPP11
                in all call centers. (Note: Uniform means equal in functionality not
                capacity).
   579          The enterprise UCD system must include a voice recognition                SUPP12
                capability.
   580          The UCD system must operate as a single, statewide call center that      FCTN760
                will route calls to agents without regard to location.
   581          The enterprise UCD system must include a background music                FCTN762
                function for calls that are waiting in a queue.
   582          The enterprise UCD system must include an announcement function          FCTN763
                (for announcements recorded by EDD) for calls that are waiting in a
                queue.
   583          The enterprise UCD system must be capable of adding and                  FCTN764
                subtracting cells to the IVR tree.
   584          The IVR portion of the UCD system must accept an 800 number entry        FCTN765
                below the top tree level.
   585          The UCD system must automatically reroute calls to remaining call        FCTN766
                centers in the event one or more call centers are not available.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                               MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
UIMOD PROJECT                                                     SECTION 6C — PAGE 99 of 178



6C.5.7        800 Number Requirements
                                                                                                          Bidder
Requirement
                                             Requirement                                      State Use   Agrees
Number
                                                                                                          (Y/N)
   586        The UCD system must have the ability to add published 800 numbers               SUPP13
              as necessary.
   587        The Contractor must provide an 800 number for testing of the UCD                SUPP14
              system.
   588        The 800 number service capacity for call centers must be dynamic so             SUPP757
              that EDD will be charged for only the 800 number capacity that it uses.
   589        The UCD system must accept calls from one or more published 800                 FCTN768
              numbers and use the current 800 numbers if desired.



6C.5.8        Skills-Based Routing
The EDD staff has identified 24 skills categories for conditional call routing based upon caller
characteristics and input to the UCD system. The Skills-based Routing categories are
identified in Appendix B - Skills Definitions Matrix.

                                                                                                          Bidder
Requirement
                                             Requirement                                      State Use   Agrees
Number
                                                                                                          (Y/N)
   590        The UCD system must route calls to staff by matching the caller                 FCTN769
              characteristics and input to the skills of staff to respond to caller needs
              for services and information.

   591        The UCD system must include a Skills-Based Routing Table that will              FCTN770
              identify EDD staff who will use the UCD system and their skills
              profiles.
   592        Skills-Based Routing must be dynamic from local or remote locations;            FCTN771
              i.e., authorized EDD staff must be able to change skill profiles based
              on service needs and changes in staff skill levels.
   593        The UCD system must allow EDD authorized staff to set priorities on             FCTN772
              services using the dynamic Skills-Based Routing Table.
   594        The UCD system‘s Skills-Based Routing approach must meet the                    FCTN773
              languages requirements of the Dymally-Alatorre Bilingual Services
              Act.



6C.5.9        Telephony Requirements
                                                                                                          Bidder
Requirement
                                             Requirement                                      State Use   Agrees
Number
                                                                                                          (Y/N)
   595        The enterprise UCD system must include a telephone handset and                  FCTN767
              headset at each desktop for all EDD staff using the UCD system.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                    MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 100 of 178


                                                                                                       Bidder
Requirement
                                            Requirement                                    State Use   Agrees
Number
                                                                                                       (Y/N)
   596        The System must provide a means for EDD personnel to make Adds,              FCTN1221
              Moves, and Changes to the telephony user configuration and system
              features.
   597        The System must provide an electronic phone directory available to           FCTN1222
              each telephony user.
   598        The System must interface with the existing external paging systems          FCTN1223
              (loud speaker) and provide the ability to access the paging system
              using a telephone set. It must provide internal paging by zone,
              location, or all page (codes).
   599        The System must provide Call forwarding (busy, don't answer, variable        FCTN1224
              unlimited, follow me) and call transfer.
   600        The System must provide the Do Not Disturb functionality.                    FCTN1225
   601        The System must provide direct inward dialing and direct outward             FCTN1226
              dialing.
   602        The System must provide for off premise stations.                            FCTN1227
   603        The System must provide for shared tenant service (partitioning).            FCTN1228
   604        The System must provide for a uniform dialing plan.                          FCTN1229
   605        The System must provide for virtual extensions.                              FCTN1230
   606        The System must provide the ability to automatically perform a backup        FCTN1232
              without losing call statistics if a power failure occurs.
   607        The System must provide the ability for supervisors, from their phone        FCTN1233
              sets, to log an agent off their respective phone set.
   608        The System must provide the ability to remotely diagnose and fix             FCTN1234
              telephony problems.
   609        The System must provide three and six way conference calling.                FCTN1235
   610        The System must provide Extension dialing using 4 to 5 digits.               FCTN1236
   611        The System must include a music source and comply with all related           FCTN1237
              laws.
   612        The System must provide Speed Calling, group and individual.                 FCTN1238
   613        The System must provide automatic call route selection, class of             FCTN1239
              service, and class of service restriction for outbound calls.
   614        For internal calls, the System must provide for Station Line ID (display     FCTN1240
              of name and number) of the caller on the telephone instrument.
   615        The System must provide Auto callback for incoming calls.                    FCTN1241
   616        The System must provide call waiting, call pick up, and call park.           FCTN1242
   617        The System must provide Call hunting and a unified method of                 FCTN1243
              distributing calls.
   618        The System must provide 24X7 capability for IVR messages to be               FCTN1244
              recorded and activated from remote locations.


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 101 of 178


                                                                                                      Bidder
Requirement
                                            Requirement                                   State Use   Agrees
Number
                                                                                                      (Y/N)
   619        The System must provide the ability for the user to put self in make        FCTN1245
              busy or a variety of not ready modes.
   620        The System must be able to support Unified Messaging application.           FCTN1246
   621        The System must be able to implement an auto-registration process           FCTN1247
              that registers a "rogue" telephone on the network to automatically
              report to an EDD administrator.
   622        The enterprise UCD must include voice mail for all EDD staff using the      FCTN1248
              System.
   623        Voice mail must provide for up to 50 two (2) minute voice mail              FCTN1249
              messages.
   624        Voice mail must provide the capability for a caller to transfer to an       FCTN1250
              attendant in addition to or in lieu of leaving a message.
   625        Voice mail must provide a date/time stamp for every message left.           FCTN1251
   626        Voice mail must provide the ability for a user to broadcast a message       FCTN1252
              to multiple voice mail boxes within the System.
   627        Voice mail must provide the capability to personalize the main and          FCTN1253
              alternate greeting.
   628        Voice mail must provide the capability for a number associated with         FCTN1254
              the primary number to use the same voice mail box.
   629        Voice mail must provide the capability for an announce only mailbox,        FCTN1255
              as well as a announce record mail box.
   630        Voice mail must provide the capability for each user to customize their     FCTN1256
              password to access their voice mail. This password must be secure
              and not available to the system administrator.
   631        Voice mail must provide the capability for a message to be recorded         FCTN1257
              and marked for future delivery.
   632        Voice mail must provide the capability for a voice message to be sent       FCTN1258
              with different brands, from normal to emergency delivery.
   633        Voice mail must provide the capability for remote retrieval of              FCTN1259
              messages from outside of the System.
   634        Voice mail must provide the capability to forward messages within the       FCTN1260
              System.
   635        Voice mail must provide cell phone and pager notification.                  FCTN1261
   636        Voice mail must provide the ability for a User to save, review, scan,       FCTN1262
              repeat, skip, erase, and retrieve erase (during the same session).
   637        The System must have the ability to interface with the paging and           FCTN1263
              cellular service company to notify (page) users when voice mail
              messages are marked urgent.
   638        Voice mail must provide the capability for a user to reply to a voice       FCTN1264
              message left by another user within the System.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 102 of 178


                                                                                                       Bidder
Requirement
                                             Requirement                                   State Use   Agrees
Number
                                                                                                       (Y/N)
   639        Voice mail must provide a visual indicator when a message is waiting         FCTN1265
              to be retrieved.
   640        The UCD telephone set must have a secondary outbound and inbound             FCTN1266
              telephone line.
   641        The UCD telephone set must have an LED display that can display:             FCTN1267
              a) The UCD destination telephone number,
              b) Date and time (when not in use),
              c) Routing table and call type,
              d) ANI of the caller, and
              e) Name of caller for internal calls.
   642        The UCD telephone set must have administrator programmable keys              FCTN1268
              so that an agent can log on and off of the UCD, enter codes (such as
              walk codes and line of business codes). This will be stored in the UCD
              for retrieval and reporting.
   643        The UCD telephone set must have multiple line appearance capability.         FCTN1269
   644        The UCD telephone set must have group intercom capability.                   FCTN1270
   645        The UCD telephone set must have function keys for transfer, hold,            FCTN1271
              release, link, mute, individual autodial, and other functions.
   646        The UCD telephone set must have Distinctive ringing.                         FCTN1272
   647        The UCD telephone set must have last number redial.                          FCTN1273
   648        The UCD telephone set must have speakerphone-full duplex capability          FCTN1274
              on predestinated telephones.
   649        The UCD telephone set must have off hook alarm.                              FCTN1275
   650        The UCD telephone set must have hands free calling and intercom.             FCTN1276
   651        The UCD telephone set must have Elapsed Call Timer (shows the                FCTN1277
              elapsed time of a call).
   652        The UCD telephone must be inline powered from the PBX.                       FCTN1278
   653        The UCD telephone must have ringer cutoff and ringing tone control.          FCTN1279
   654        The UCD PBX must have minimal telephone service (receiving and               FCTN1280
              making calls at predestinated stations) in the event of a power failure.
   655        The UCD telephone must be digital and can accept IP-based calls,             FCTN1281
              VoIP based calls, local calls and PSTN calls.
   656        The UCD System must have the ability to log on and off of the UCD            FCTN1306
              system, enter codes (such as walk codes and line of business codes)
              that will be stored in the UCD system for retrieval and reporting.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 103 of 178



6C.5.10       UCD Configuration Update Requirements
                                                                                                       Bidder
Requirement
                                             Requirement                                   State Use   Agrees
Number
                                                                                                       (Y/N)
   657        For functionality, scripting, and routing configuration, the UCD must be     FCTN774
              table driven rather than code driven. Authorized EDD end-users and
              technical staff must have access to update the tables.
   658        The System must allow end users and technical staff the ability to           FCTN775
              update the UCD without Contractor assistance for:
              a) Skill-Based Routing,
              b) Changes to Call Scripts,
              c) Changes to the routing of calls (i.e., creating, changing, activating
              and de-activating routings instructions),
              d) Changes to the UCD system configuration for call routing, such as,
              adding and deleting routes and its background configuration,
              e) Scheduling routing instructions to implement at set days or times of
              day, and
              f) Adding new scripts and deleting old scripts.


6C.5.11       Operational Management Requirements
                                                                                                       Bidder
Requirement
                                             Requirement                                   State Use   Agrees
Number
                                                                                                       (Y/N)
   659        The System must provide EDD the ability to record announcements              FCTN759
              and UCD system responses to user inquiries.
   660        The UCD must include a management function and control panel view            FCTN776
              from local or remote locations.
   661        The System must allow EDD the ability in its central management              FCTN777
              location and from remote locations to add or subtract call centers from
              the routing matrix dynamically, based upon workload.
   662        The call center UCD installation must include displays that will show        FCTN778
              information on status of calls by skill set. The displays must be
              configurable both locally and centrally.
   663        The System must allow EDD the ability to configure the UCD both              FCTN779
              locally and remotely.
   664        The System must allow EDD the ability to view and manipulate agent           FCTN780
              status, in near real-time (1-3 seconds), from selected locations within
              the call centers, the two UI Division offices, a central management
              location, and remote management locations.
   665        The System must allow EDD the ability to reassign call center agent          FCTN781
              positions in the UCD system centrally, remotely, or locally.
   666        The UCD must include a facility for managing queue sizes based on a          FCTN782
              priority of service.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 104 of 178



6C.5.12       Back-Up and Recovery Requirements
                                                                                                         Bidder
Requirement
                                             Requirement                                     State Use   Agrees
Number
                                                                                                         (Y/N)
   667        The UCD system must include full weekly back-ups of all files and              SUPP20
              system software with daily, incremental back-up, of software changes.
   668        The UCD custom software and data and any changes to software                   SUPP21
              must be backed-up on a daily basis.
   669        Data retained by the UCD for reporting on UCD system must be                   SUPP22
              backed-up on a daily basis. In addition, the UCD system must retain a
              transaction file that will be used to rebuild the reporting data file in
              case of corruption. All software must have a copy for each
              administrative machine located with the machine in a secured location.
   670        The Contractor must construct the System so that back-up procedures            SUPP23
              for the UCD system can be operated by authorized staff.
   671        In case of file corruption or equipment failure, the System must               SUPP82
              automatically fail-over to the redundant server.


6C.5.13       General Technical Requirements
                                                                                                         Bidder
Requirement
                                             Requirement                                     State Use   Agrees
Number
                                                                                                         (Y/N)
   672        The UCD system must provide help functionality at the system                   SUPP24
              administrator level to facilitate common maintenance and
              administration functions.
   673        The UCD system must include all support software, tools and utilities          SUPP25
              (e.g. compilers, text editors, library products, code generators, scripts)
              needed to perform configuration, installation, operation and
              management tasks.
   674        The UCD client application must be interoperable with EDD desktop              SUPP26
              software standards (e.g. productivity tools, virus protection, etc.).
              These standards are available in the Bidders' Library.
   675        The UCD system must provide transaction logs to record executed                SUPP29
              functions to facilitate diagnosis and reconciliation of UCD system
              errors. These logs must be available to EDD.
   676        The UCD system must provide online system administration                       SUPP299
              documentation that is indexed and searchable.
   677        The Contractor must provide UCD system source code and version                 SUPP300
              control utilities within a tool that is acceptable to EDD.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                   MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 105 of 178



6C.5.14       Performance Characteristics Requirements
                                                                                                        Bidder
Requirement
                                            Requirement                                     State Use   Agrees
Number
                                                                                                        (Y/N)
   678        The Contractor must define additional lines and equipment that must           SUPP40
              be added to the DTS Network and/or elsewhere to meet performance
              requirements of the UCD system.
   679        For the UCD system, blockage factors (no dial-tone) must occur at a           SUPP41
              rate of no more than 0.001 percent; i.e., 99.999 percent availability.
   680        For the UCD system, cut-through (e.g., Transmission Time) from IVR            SUPP42
              to queue must occur at an average rate of 2000 milliseconds or less.
   681        For the UCD system, cut-through from queue to agent must be 500               SUPP43
              milliseconds or less.



6C.5.15       Information Management
Information management includes stewardship of data collected by the UCD and
retained in the UCD reporting system as well as data that is temporarily retained by the
UCD and then transmitted to other systems for storage. Data that is collected by the
Continued Claims Subsystem is considered mission critical. Performance data used for
reporting and kept by the UCD is considered business critical.


                                                                                                        Bidder
Requirement
                                            Requirement                                     State Use   Agrees
Number
                                                                                                        (Y/N)
   682        Business critical data retained in the UCD reporting system must be           SUPP56
              ―backed-up‖ on a daily basis with back-up media stored in a secondary
              location.
   683        For the UCD reporting system, the UCD must maintain transaction               SUPP57
              files that can be used to restore data in case of database failure in the
              reporting system between back-ups.
   684        Mission critical data received from callers regarding Continued Claim          IFACE5
              Certification is mission critical and must be guaranteed deliverable
              (e.g., ―mirrored‖) in real time so that all data is redundantly retained
              until it is batched processed to SCDB. The UCD system must include
              automatic ―fail-over‖ to the redundant source in case of failure in the
              primary storage facility.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 106 of 178



6C.5.16       System Operations Requirements
                                                                                                        Bidder
Requirement
                                            Requirement                                     State Use   Agrees
Number
                                                                                                        (Y/N)
   685        The UCD system must be configured redundantly so that in case of              SUPP59
              network or equipment failure, or other administrative contingency, at
              one or more call centers, the UCD will automatically reconfigure call
              routing to the remaining call centers.
   686        The UCD system design must allow EDD staff to modify, add, or                 FCTN856
              delete functionality or modules (including the tree structure) in the IVR
              application.
   687        The UCD system must include remote configuration and management               FCTN1216
              for all equipment and applications.



6C.5.17       System Human Factors Requirements
                                                                                                        Bidder
Requirement
                                            Requirement                                     State Use   Agrees
Number
                                                                                                        (Y/N)
   688        The UCD system must include error handling routines such that the             SUPP61
              UCD system will automatically recover from errors due to incorrect
              input of information by callers.
   689        The UCD system must include error handling routines for interfaces             IFACE6
              that will allow completion of the interface by removing data that does
              not meet edit requirements of the receiving system and producing
              reports of all data that could not be written to the receiving system due
              to error conditions.
   690        For EDD agents, use of the UCD system must be in compliance with              FCTN857
              the Americans with Disabilities Act.



6C.5.18       System Maintainability
The Contractor is responsible for quality of service and uptime for all equipment and
network operations with the exception of network data lines that connect the EDD
central office to remote locations using the DTS Network. The EDD will initiate a
separate Service Level Agreement with DTS to cover Quality of Service (QoS),
performance, and reliability of the Network. The UCD system maintenance
requirements are found in the RFP Section 6B, System Engineering Requirements.

                                                                                                        Bidder
Requirement
                                            Requirement                                     State Use   Agrees
Number
                                                                                                        (Y/N)
   691        The UCD system must leverage EDD event notification applications to           SUPP67
              notify staff in the event of predictive and non-predictive outages to
              provide real-time response.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 107 of 178


                                                                                                     Bidder
Requirement
                                           Requirement                                   State Use   Agrees
Number
                                                                                                     (Y/N)
   692        The Contractor must provide an event management application that           SUPP844
              monitors the UCD system, notifying staff of predictive and non-
              predictive outages. This event manager must have the ability to notify
              staff with means other than network connectivity, such as a modem for
              event delivery. (Predictive outages occur when EDD-configured UCD
              system threshold settings are exceeded.)



6C.5.19       Equipment and Software Requirements
                                                                                                     Bidder
Requirement
                                           Requirement                                   State Use   Agrees
Number
                                                                                                     (Y/N)
   693        System installation and operation of equipment and software related to     SUPP68
              the CCNPAU project must comply with State of California regulations
              established by the DTS Data Center, the Employment Development
              Department, State CIO or DOF/CISO administrative policy, and any
              other relevant legislated public policy. Copies of or references for
              these regulations and policies can be found in the Bidders' Library.



6C.5.20       Architectural Design Requirements - VoIP Solution
The proposed architectural approach to providing a UCD to meet the UI Program‘s needs
uses a Voice-over-Internet Protocol (VoIP) approach. In a VoIP network, all voice
communications are digitized and carried as digital packets on the same network transport
system that carries data. There is no need for a local device to handle communication with
the UCD or rerouting of calls as the UCD has control over both data and voice
communications on the same network. This is shown in the figure below.
In summary, analog T1 lines connect the UCD to the Public Switched Telephone Network
(PSTN). Calls are received by the UCD and converted into digital data before being
distributed to the Call Centers using a Skills-based Routing system that is incorporated in
the UCD. Distribution of calls occurs over a digital network of T1 lines to 15 Call Centers
that also carry data regarding callers and services. A voice-data gateway Call Center
converts the voice data so that agents and callers may speak to each other. The voice-data
gateway is, in essence, an extension of the VoIP UCD. No additional equipment is
necessary to keep the central location informed of call status.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                               MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                 RFP OSI 7100-181
UIMOD PROJECT                                                     SECTION 6C — PAGE 108 of 178




                                                     UCD




                                              1's
                                    Data Network T




      Voice Data                  Voice Data                    Voice Data


       Gateway                    Gateway                        Gateway


                                          IP                           IP
           IP Phone      Switch         Phone          Switch        Phone      Switch

                                                       PC                               PC
                          PC
                                                                UI Agent
                                            UI Agent
                   UI Agent                                                  UI Agent




                   Figure 6C.2 Voice over Internet Protocol Configuration
This approach has several advantages over traditional telephony:
   1. It is less complex because there is only one network and no local communication
      servers or ―shelves.‖
   2. The configuration can be more easily scaled upward from a central location.
   3. End-to-end monitoring and reporting is more easily accomplished because there
      is only one network carrying both voice and data.
   4. The approach is more efficient (i.e., requires fewer T1 lines). VoIP includes
      compression of voice data so that the bandwidth that is needed is about ¼ of
      what would be required otherwise.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                     MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                         RFP OSI 7100-181
UIMOD PROJECT                                             SECTION 6C — PAGE 109 of 178



6C.5.21       Network Diagrams
The Network Diagrams for the VoIP approach are found in Appendix H - Network Diagrams
- VoIP.

6C.5.21.1     Data Network Protocol Stack

The existing and proposed Wide Area Network (WAN) data network is CSGNet operated by
DTS.
The WAN backbone consists of multiple DS3/OC3 circuits provided by and managed by the
DTS. LATA hub sites are connected to the backbone via a DS3 point-to-point circuit.
Firewalls are located in each LATA hub site, creating security domain for EDD offices.
Connection to remote offices from the LATA hub site is through the use of DS3 ATM circuits
to Frame Relay circuits at the remote office. Network management is divided between EDD
and DTS. DTS manages all routers, and EDD is responsible for managing firewalls and
LAN switches.
There are fifteen UI remote business locations (including the Primary Call Centers, Primary
Adjudication Centers, and the Insurance Accounting Division). Twelve of the locations are
connected to the LATA hubs by Frame Relay. Three of the locations are combined with a
LATA hub and do not have a Frame Relay connection to the LATA hub. The gateway and
monitoring/management facilities are centrally located.


6C.5.21.2     Data Network Protocol Stack - Application Layer Requirements
                                                                                              Bidder
Requirement
                                         Requirement                              State Use   Agrees
Number
                                                                                              (Y/N)
   694        The Data Network Application Layer must support the current CRM     SUPP85
              Desktop with screen pops of information from the Single Client
              Database.

6C.5.21.3     Interactive Voice Response (IVR) Requirements
The IVR will run on top of the current data network. Proposed additions to the data network
must support the additional capacity required by the new IVR applications and the data
needs for those applications.
                                                                                              Bidder
Requirement
                                         Requirement                              State Use   Agrees
Number
                                                                                              (Y/N)
   695        The Data Network Application Layer must support the new CCNPAU      SUPP86
              and CCR Applications.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                        MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 110 of 178



6C.5.21.4     E-mail
The email system will run on top of the current data network. Proposed additions to the data
network must support the current email system.

                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   696        Proposed Additions to the data network must not conflict with the EDD     SUPP87
              email system, Microsoft Exchange / Outlook.



6C.5.21.5     Web Browsing
Agents currently use Web Browsing for research purposes. The proposed data network
additions must support Web Browsing

                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   697        The Data Network Application Layer must support Web Browsing.             SUPP88



6C.5.21.6     Document, Imaging and Storage
EDD is in the planning stage of a new scanned document viewing system. The proposed
data network additions must be capable of supporting Document Imaging applications.
(NOTE: Capacity planning for the current network is scaled to the CCNPAU applications
only.) Distributed electronic document viewing will require additional bandwidth to be added
to the system.

                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   698        The data network must have the capability to support electronic           SUPP89
              document viewing applications.



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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                              MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 111 of 178




                                                                                                   Bidder
Requirement
                                            Requirement                                State Use   Agrees
Number
                                                                                                   (Y/N)
   699        The Data Network Application Layer must support new proposed CTI         SUPP90
              applications.
   700        If new proposed CTI applications require a different transport layer     SUPP91
              than is currently in place, the Contractor must supply the network
              components and equipment to support this application, and it must
              meet the security standards required of the current data network.
   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     Data Network Protocol Stack - Transport Layer Requirements
                                                                                                   Bidder
Requirement
                                            Requirement                                State Use   Agrees
Number
                                                                                                   (Y/N)
   702        The Data Network transport layer must comply with the current            SUPP92
              network transport infrastructure.



6C.5.21.9     Data Network Protocol Stack - Network Interface and Hardware
                    Requirements
                                                                                                   Bidder
Requirement
                                            Requirement                                State Use   Agrees
Number
                                                                                                   (Y/N)
   703        Equipment that must interface with the data network must meet one of     SUPP93
              the EDD network management solutions found in the Bidders' Library.
   704        All NIC cards must be at least Tbase100. All equipment must be           SUPP94
              CAT5 TCP/IP compatible.

6C.5.21.10    Data Transport Layer

The Transport layer includes:
     1. WAN transport via DS3/OC3.
     2. LATA hub to the Call Centers Frame Relay T1 Circuits.
     3. LAN consisting of CAT5e and CAT6 using TCP/IP

                                                                                                   Bidder
Requirement
                                            Requirement                                State Use   Agrees
Number
                                                                                                   (Y/N)
   705        The Data Network transport layer must comply with the current            SUPP95
              network transport layer. For the LAN this includes CAT5 / CAT6
              cabling and TCP/IP.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                             MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 112 of 178


                                                                                                     Bidder
Requirement
                                            Requirement                                  State Use   Agrees
Number
                                                                                                     (Y/N)
   706        The data network backbone must continue to be managed by DTS.              SUPP96
              The LAN equipment on the LATA side of the firewall will continue to be
              managed by EDD. Contractor approach must be compatible with this
              constraint.



6C.5.21.11    Topology

WAN transport is through the CSGNet backbone. Call Centers are supported by hubs in
various LATAs. The LATA hubs are connected to the backbone via DS3. Call Centers are
either co-located with the LATA hub or connected to the LATA hub via Frame Relay link.
                                                                                                     Bidder
Requirement
                                            Requirement                                  State Use   Agrees
Number
                                                                                                     (Y/N)
   707        Each workstation area is configured with two RJ-45 Network                 SUPP97
              connections.
   708        The UCD may reside in the PSTN. The System must terminate calls            SUPP98
              coming in from the PSTN and distribute calls to the agents at the call
              centers.
   709        Equipment connected to the call center LAN must conform to the             SUPP99
              current LAN topology.
   710        Equipment connected via WAN must connect across the WAN                    SUPP100
              managed by DTS. Any equipment that will connect via PSTN/WAN
              must include all required equipment associated with the PSTN/WAN.
   711        The System must be configured with a central UCD with local VoIP           SUPP301
              systems at each call center. Contractor supplied telephones must
              connect to the existing LAN within each call center. While it is
              possible that the UCD will reside in the PSTN, the local call centers
              must have local VoIP equipment, such as VoIP Gateways and VoIP
              switches, to distribute the calls to the agents.
   712        There must be no call queuing at the local sites.                          FCTN886



6C.5.21.12    Data Network Addressing- Static/Dynamic

EDD uses public Internet Protocol (IP) addresses for remote offices; all locations are
allocated from two (2) Class B subnets. Additional address blocks from the current Class B
are available dependent on the design of the CCNPAU system. Proxy addressing is not an
option.
                                                                                                     Bidder
Requirement
                                            Requirement                                  State Use   Agrees
Number
                                                                                                     (Y/N)
   713        Equipment that connects to the LAN/WAN must be DHCP enabled.               SUPP101




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                               MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 113 of 178


                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   714        Equipment that connects to the LAN/WAN requiring a static IP address      SUPP102
              must require issuance of an IP address from DTS through the EDD
              Network Group.



6C.5.22       Management and Administration

6C.5.22.1     Protocol Requirements

Equipment within the LAN/WAN is viewed using EDD/DTS network monitoring systems.
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   715        Equipment that connects to the LAN/WAN must be SNMP enabled.              SUPP103
   716        Equipment (i.e., routers and switches) that is installed at EDD sites     SUPP105
              must meet EDD standards. The equipment must also be compatible
              with EDD standard security, audit, and control provided by
              radius/tacacs+. The equipment will be maintained by EDD staff and
              will conform to current EDD backup methodologies across the
              LAN/WAN (See the Bidders' Library).



6C.5.22.2     Applications
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   717        Equipment that connects to the LAN/WAN must be viewed using               SUPP104
              EDD/DTS network monitoring systems.
   718        Equipment that connects to the LAN/WAN must communicate using             SUPP626
              network protocols that are supported by the current LAN/WAN.

6C.5.22.3     Alarms Requirements
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   719        Contractor must ensure that the SNMP Management Information Base          SUPP106
              (MIB) and SNMP traps are in place throughout equipment and network
              management systems and perform any integration necessary so that
              the alarms are viewable on the EDD/DTS monitoring systems.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                              MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 114 of 178



6C.5.22.4     Redundancy Requirements
                                                                                                          Bidder
Requirement
                                             Requirement                                      State Use   Agrees
Number
                                                                                                          (Y/N)
   720        Equipment within the System that presents a potential point of failure          SUPP107
              affecting a service outage for callers or users must be addressed by
              redundancy at that point providing automatic failover in the case of
              failure of the primary component.
   721        Any non-redundant components within the System that are potentially             SUPP108
              a service affecting point of failure must be specifically identified in the
              Contractor solution.



6C.5.22.5     Network Software Intelligence Requirements
                                                                                                          Bidder
Requirement
                                             Requirement                                      State Use   Agrees
Number
                                                                                                          (Y/N)
   722        Equipment within the System that provides switching capability must             SUPP109
              be dynamically configurable via remote access.



6C.5.22.6     Agent Status Monitor Requirements
                                                                                                          Bidder
Requirement
                                             Requirement                                      State Use   Agrees
Number
                                                                                                          (Y/N)
   723        Agent status throughout the system must be viewable in real time from           FCTN874
              central and local sites.
   724        Reporting, summary, and detailed information must be available for              FCTN875
              agent status throughout the system on an on-demand basis from
              central and remote sites.



6C.5.22.7     Telephone Trunk Monitor Requirements
                                                                                                          Bidder
Requirement
                                             Requirement                                      State Use   Agrees
Number
                                                                                                          (Y/N)
   725        All trunk status within the System must be SNMP enabled and                     SUPP110
              viewable through EDD/DTS network monitoring systems.



6C.5.23       Equipment
The requirements below include those regarding new telephones; new telephones may
need to be connected to the existing DTS/EDD LAN/WAN, and they must be compatible
with that LAN/WAN for purposes of status monitoring and reporting.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                    MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 115 of 178



6C.5.23.1     Data Network

6C.5.23.1.1 Access Points Requirements
                                                                                                       Bidder
Requirement
                                            Requirement                                    State Use   Agrees
Number
                                                                                                       (Y/N)
   726        All new Data Network access points must be compatible with the               SUPP112
              existing DTS/EDD LAN/WAN and must be approved by EDD (See the
              Bidders' Library).



6C.5.23.1.2 Switches Requirements
                                                                                                       Bidder
Requirement
                                            Requirement                                    State Use   Agrees
Number
                                                                                                       (Y/N)
   727        All new switching equipment that accesses the existing DTS/EDD               SUPP113
              LAN/WAN must be compatible with that LAN/WAN and meet EDD
              Standards (See the Bidders' Library).



6C.5.23.1.3 Routers Requirements
                                                                                                       Bidder
Requirement
                                            Requirement                                    State Use   Agrees
Number
                                                                                                       (Y/N)
   728        All new routers that access the existing DTS/EDD LAN/WAN must be             SUPP114
              compatible with that LAN/WAN and will be SNMP enabled.



6C.5.23.1.4 Network Management Requirements
                                                                                                       Bidder
Requirement
                                            Requirement                                    State Use   Agrees
Number
                                                                                                       (Y/N)
   729        All network devices accessing DTS/EDD must be compatible with                SUPP115
              EDD‘s current network management and meet EDD‘s standards.
   730        The Contractor must construct each site network to employ network            SUPP116
              data classification, bandwidth control, and application control devices.
              The network must be compatible with EDD‘s current network
              management (at the time of contract award) and meet EDD‘s network
              standards (See the Bidders' Library).




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 116 of 178



6C.5.23.1.5 Mean Time Between Failures (MTBF) Requirements
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   731        All new data network equipment provided must have an MTBF                 SUPP124
              specified such that the System as a whole, with redundancy and
              sparing considered, will conform to the industry standard of 99.999%
              availability.



6C.5.23.2     Servers Requirements
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   732        All new Client/Server servers that access the existing DTS/EDD            SUPP117
              LAN/WAN must be compatible with that LAN/WAN.
   733        All new Database servers that access the existing DTS/EDD                 SUPP118
              LAN/WAN must be compatible with that LAN/WAN.



6C.5.23.3     Telecommunications

6C.5.23.3.1 Telecommunications Requirements
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   734        The Contractor must construct the System so that the EDD will have        FCTN876
              the capability to create new IVR applications, define new skill sets,
              define new UCD queues and configure new call center routing
              parameters.
   735        The EDD must have the ability to define new skill sets.                   FCTN1212
   736        The EDD must have the ability to define new UCD Queues.                   FCTN1213
   737        The EDD must have the ability to configure new call center routing        FCTN1214
              parameters.
   738        System applications within the UCD (ACD, SBR, and IVR) must be            SUPP131
              scaleable in terms of both new IVR application types and new call
              center and skill set types.
   739        The UCD must be extensible to other new applications such as              SUPP132
              outbound calling and predictive dialing.



Dynamic capacity modification at all switching points is required. The Bidder solution
must specify the plan for dynamic modification of inbound/outbound capacity of all
telecommunication switch points within the system.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                              MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 117 of 178



6C.5.23.3.2 Dynamic Capacity Modification – Network Requirements
                                                                                                      Bidder
Requirement
                                            Requirement                                   State Use   Agrees
Number
                                                                                                      (Y/N)
   740        The UCD must be capable of dynamic modification of capacity.                SUPP133
   741        VoIP Switch/Routing points within the System must be capable of             SUPP134
              dynamic capacity modification.



6C.5.23.3.3 Dynamic Capacity Modification - IVR Requirements
                                                                                                      Bidder
Requirement
                                            Requirement                                   State Use   Agrees
Number
                                                                                                      (Y/N)
   742        The central IVR within the System must be capable of dynamic                SUPP135
              modification of capacity.



6C.5.23.3.4 VoIP Requirements
                                                                                                      Bidder
Requirement
                                            Requirement                                   State Use   Agrees
Number
                                                                                                      (Y/N)
   743        The System must include the ability to filter and separately log or not     SUPP143
              log VoIP traffic for security logging, monitoring, and audit purposes.
   744        The System must comply with the Session Initiation Protocol (SIP)           SUPP302
              standards for establishing VoIP connections as specified by the
              Internet Engineering Task Force (IETF RFC 2543).
   745        Security access controls must include monitoring, logging and audit of      SUPP623
              the UCD.



6C.5.23.4       Data Network Modularity

6C.5.23.4.1 Isolation for Security
Currently, each LATA Hub includes a firewall. Call center sites, (and other EDD sites),
connect behind these LATA firewalls. Where call center sites include non-EDD
(Contractor‘s) maintained equipment, this equipment must be fire walled from the EDD
enterprise network.New network connections must conform to this security approach. Each
cluster (servers, switches, routers, etc.) whether within an EDD Call Center or in the central
office must be behind a firewall connected to the DTS/EDD WAN using security
conventions.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 118 of 178



6C.5.23.4.2 Isolation for Security Requirements
                                                                                                  Bidder
Requirement
                                          Requirement                                 State Use   Agrees
Number
                                                                                                  (Y/N)
   746        New network connections must conform to this modularity standard,      SUPP144
              with each cluster either within an EDD call center or in the central
              office behind a firewall connected to the DTS/EDD WAN using
              security conventions.



6C.5.23.5       Data Network Quality of Service (QoS)
The Internet Protocol was designed for carrying data so an intensive real-time application
like voice delay runs under a threshold value that would be acceptable for the user (QoS).
The minimum voice quality compression algorithm required is G.729.A. G.711, G.723.1,
and G.729 are also valid compression algorithms but require more bandwidth allocation.
Where proposed additions to the data network require static bandwidth allocation, the
Contractor must provide a list of all static address devices, reason for static allocation, and
type of static allocation. This listing is subject to approval by EDD before installation.

6C.5.23.5.1 QoS – Maximum Capacity
                                                                                                  Bidder
Requirement
                                          Requirement                                 State Use   Agrees
Number
                                                                                                  (Y/N)
   747        The proposed data network solution must be configured at 40            SUPP146
              percent capacity at maximum load.
   748        The System must provide for estimated maximum load for all data        SUPP147
              network additions.
   749        In the Contractor solution, the System must provide for estimated      SUPP148
              average load for all proposed additions to the data network.



6C.5.23.5.2 Estimated Maximum Load Requirements
                                                                                                  Bidder
Requirement
                                          Requirement                                 State Use   Agrees
Number
                                                                                                  (Y/N)
   750        The Contractor must establish a data network baseline and establish    SUPP624
              applications estimated baselines related to capacity planning for
              current network as scaled to the CCNPAU application.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                             MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                               SECTION 6C — PAGE 119 of 178



6C.5.23.5.3 Packet Loss Requirements
                                                                                                 Bidder
Requirement
                                         Requirement                                 State Use   Agrees
Number
                                                                                                 (Y/N)
   751        Proposed additions to the data network must be designed to allow a    SUPP149
              maximum of 0.1 percent packet loss.
   752        The UCD installation must include the means to measure and            SUPP625
              monitor packet loss.



6C.5.23.5.4 Latency Requirements
                                                                                                 Bidder
Requirement
                                         Requirement                                 State Use   Agrees
Number
                                                                                                 (Y/N)
   753        Proposed additions to the data network must be designed to permit     SUPP150
              a maximum of 200ms latency.



6C.5.23.5.5 Availability / Reliability Requirements
                                                                                                 Bidder
Requirement
                                         Requirement                                 State Use   Agrees
Number
                                                                                                 (Y/N)
   754        Proposed additions to the data network must be designed to provide    SUPP151
              99.999% reliability and availability.



6C.5.23.5.6 Jitter Requirements
                                                                                                 Bidder
Requirement
                                          Requirement                                State Use   Agrees
Number
                                                                                                 (Y/N)
   755        Proposed additions to the data network must be designed to minimize    SUPP152
              Jitter.



6C.5.23.6      Bandwidth Allocation
Where proposed additions to the data network require static bandwidth allocation, the
Contractor must provide a list of all static address devices, reason for static allocation, and
type of static allocation. This listing is subject to approval by EDD before installation.

                                                                                                 Bidder
Requirement
                                          Requirement                                State Use   Agrees
Number
                                                                                                 (Y/N)
   756        Proposed additions to the data network must allow for dynamic          SUPP153
              allocation of bandwidth between applications where applicable.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                            MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 120 of 178


                                                                                                       Bidder
Requirement
                                            Requirement                                    State Use   Agrees
Number
                                                                                                       (Y/N)
   757        Where proposed additions to the data network require static bandwidth        SUPP154
              allocation the Contractor must provide a list of all static address
              devices, reason for static allocation, and the type of static allocation.



6C.5.23.7             Virtual Private Network (VPN)

6C.5.23.7.1 Remote Access Points Requirements
                                                                                                       Bidder
Requirement
                                            Requirement                                    State Use   Agrees
Number
                                                                                                       (Y/N)
   758        All remote access to the equipment added to the System must be via           SUPP155
              VPN. No other remote access will be allowed within the System.
   759        The Contractor must specify all devices that require VPN access.             SUPP156
   760        The Contractor must identify the VPN software to be used and certify         SUPP157
              that the VPN approach meets California standards and is compatible
              with the network and equipment currently in use.
   761        All VPN Access software and equipment must comply with EDD/DTS               SUPP158
              standards (See the Bidders' Library).




6C.5.24       Telecommunications Capacities
Capacity is determined by the bandwidth necessary to provide duplex conversations. By
dividing the capacity of a T1 line by the bandwidth necessary for a conversation, the
capacity of a line can be calculated. When one knows the number of concurrent
conversations the total number of T1 lines necessary to support a location can be
calculated. The VoIP bandwidth depends on a number of factors:
Duplex communications are needed to provide both sides of a telephone conversation.
Since communications go two (2) directions, traditional streaming audio calculations are not
valid to calculate bandwidth.
     1. The Coder/Decoder (CODEC) standard that is used not only determines how the
        conversation is translated from analog to digital and back again but determines the
        compression of the information.
     2. The packet frequency (how often packets are to be sent and received) also must
        be considered.
     3. Multiple file headers required for VoIP conversations add overhead to the call.
Most manufacturers recommend a packet frequency of 20 ms. Even single manufacturers
(e.g., CISCO) list as many as seven (7) CODEC standards that can be locally configured.
These standards vary from 5.3 Kbps to 64 Kbps and yield bandwidth for a single call from

0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 121 of 178



31.5 Kbps to 87.2 Kbps for a single call. The lower the bandwidth Kbps, the more calls can
be contained in a single T1 line. However, the compression can impact the QoS.
Undoubtedly, there will be additional CODECs before the UI Modernization System is
implemented.
For this document, a conservative bandwidth was selected that yields good QoS. This
suggests that each T1 line will be able to support 96 concurrent calls (as opposed to 24
concurrent calls for an analog T1 line). Again, new CODECs and new efficiencies in line
configuration may yield better line efficiency at the point of UI Modernization Implementation.

6C.5.24.1             IVR Requirements

The IVR must be capable of dynamic capacity modifications. At maximum, it will need to
process 60,923 busy hour calls with an average three minute duration. Our calculations
show that this will require 3,249 ports to provide .001% blockage; however, the Contractor
will be responsible for ensuring that the system is capable of providing enough capacity to
meet the blockage standard at the projected system load. Calculations are based on the
Erlang B method (see Appendix F - Erlang B Calculations Method).

                                                                                                      Bidder
Requirement
                                           Requirement                                    State Use   Agrees
Number
                                                                                                      (Y/N)
   762        The IVR must be dynamically sizable and capable of handling 60,923          SUPP159
              busy hour calls with an average duration of three minutes, providing a
              blockage rate of 0.001%.



6C.5.24.2          Queuing Requirements
Queuing for the UCD is assumed to be behind the VoIP Gateway.

                                                                                                      Bidder
Requirement
                                           Requirement                                    State Use   Agrees
Number
                                                                                                      (Y/N)
   763        There must be enough trunks configured within the System so that            SUPP160
              there is capacity for one person waiting in queue for every two agents
              logged on to the UCD. (Queuing trunks equal 0.5 agent trunks.)
   764        The System must be designed so that the inbound queuing capacity            SUPP161
              can be dynamically configured to divert calls within the PSTN to a pre-
              recorded message based on a number of minutes set by EDD in the
              System configuration.
   765        The install Queue maximum queue capacity must be quoted at 10 T1            SUPP162
              lines.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 122 of 178



6C.5.24.3             Agent Lines Requirements
The system supports three (3) types of agent lines:
     1. Inbound from PSTN to UCD/ACD
     2. Inbound from UCD to Call Center
     3. Outbound from Call Center to PSTN
The system must have enough trunks from the UCD to each Call Center to support
maximum projected agents on line at the same time. The system must have enough T1
trunks from the Call Centers to the PSTN to support the maximum projected outbound
calling requirements to the agents. Blended calling would be ideal here as the agents could
go off line on their UCD phone and use their UCD line to place the outbound call that would
originate at the UCD.

                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   766        Blended Calling – Agents should be able to use their UCD lines for        SUPP163
              outbound dialing when they are not logged into the UCD.
   767        The UCD connection to the PSTN (in T1) must be variable according         SUPP164
              to the number of customer calls but sufficient to support the maximum
              number of agents on board as shown in the RFP Section 6C
              Technical Requirements Table 2 Staffing and Phones. This is
              estimated at 76 T1 lines.
   768        The System must support the following capacities from the UCD to the      SUPP758
              Call Centers for inbound calling:
                                                Telephony      Telephony
                                                 Inbound       Outbound
                         Call Center Name          T1s            T1s
                       Oakland PCC                   2             9
                       San Jose PAC                  2             6
                       San Francisco PAC             2             6
                       Sacramento PCC                1             5
                       Sacramento PAC                1             6
                       Rancho Cordova IAD            1             4
                       Los Angeles PCC               2             7
                       Los Angeles PAC               2             6
                       San Bernardino PAC            2             5
                       Riverside PCC                 1             5
                       Inglewood PAC                 1             5
                       Orange County PAC             1             6
                       Orange County PCC             2             6
                       San Diego PAC                 2             5
                       San Diego PCC                 2             7
                       Totals                       24            88




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                              MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 123 of 178


                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   769        The System must support the following total capacities for total          SUPP759
              inbound (outbound trunks) for agents and queue and IVR.
                      IVR     Queuing       Agent     Outbound         Total
                       20        4           24          88            136
   770        The Contractor must meet and be in compliance at the time of contract     SUPP621
              award, with EDD standards for any proposed server (e.g. a UNIX OS
              based system) and these servers must still meet EDD standards for
              security and hardening.
   771        Telecommunications servers, such as UCD servers, must be capable          SUPP697
              of remote configuration and maintenance across the LAN/WAN.
   772        Telecommunications applications such as UCD Capacity and wait             FCTN1220
              times must be user controllable through an application at eight (8)
              administrative locations.



6C.5.24.4             Total Capacity for Inbound and Outbound T1 Trunks
These numbers are maximums at the time of installation. Call blending and other
Contractor design specific practices may reduce these maximums. The low number of
queuing lines is achieved due to excess capacity in agent lines; i.e., all agent lines were
rounded up to the nearest T1 which created excess capacity that can be used for queuing.
Note: The outbound trunks are shown as traditional trunks, post gateway, connecting the
VoIP Switch and Gateway with the PSTN.

6C.5.24.4.1 Emergency 9-1-1 Access Requirements
                                                                                                    Bidder
Requirement
                                           Requirement                                  State Use   Agrees
Number
                                                                                                    (Y/N)
   773        The UCD must provide routing to Emergency 9-1-1 centers that are          SUPP167
              local to the agent initiating the call.
   774        The UCD must support display of the caller‘s number at the                SUPP168
              Emergency 9-1-1 center.
   775        The UCD must support display of the caller‘s location at the              SUPP169
              Emergency 9-1-1 center.



6C.5.25       Architectural Considerations

CCNPAU has adopted System Architecture requirements for IVRs. The CCNPAU system
must adhere to the adopted standards.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                              MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 124 of 178



6C.5.25.1             CCNPAU Standards Requirements
                                                                                                       Bidder
Requirement
                                            Requirement                                    State Use   Agrees
Number
                                                                                                       (Y/N)
   776        The System must be implemented as a multi-layer, multi-tier                  SUPP171
              distributed system, based on the following Worldwide Web Consortium
              (W3C Speech Interface) Framework languages:
              a) VoiceXML 2.0, 2.1
              b) Speech Recognition Grammar Specification (SRGS 1.0)
              c) Speech Synthesis Markup Language (SSML 1.0)
              d) Semantic Interpretation for Speech Grammars 1.0
              e) Call Control XML (CCXML 1.0)
   777        Layer 1 of the multi-layer system must be the Speech Browser                 SUPP172
              Platform, which includes all engines for W3C Speech Interface
              Framework languages.
   778        Layer 2 (Presentation Layer) of the multi-layer system must be the           SUPP173
              Web VXML/CCXML Document Server(s) that execute(s) portions of
              the application dialog by delivering VoiceXML or CCXML markup
              pages to the browser in response to a document request. The markup
              interpreter renders the VoiceXML/CCXML markup within an interpreter
              context, and then makes calls into the implementation platform
              components.
   779        Layer 3 (Application Layer) of the multi-layer system must consist of        SUPP174
              Business Services Providers accessible via Web Services SOAP
              Protocol. Note that this layer will be shared with other clients such as
              the CCR application.
   780        Layer 4 (Data Access Layer) of the multi-layer system must consist of        SUPP175
              a Data Access Service Provider. Note that this layer will be shared
              with other clients such as the CCR application.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                    RFP OSI 7100-181
UIMOD PROJECT                                                        SECTION 6C — PAGE 125 of 178



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 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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                         MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                          RFP OSI 7100-181
UIMOD PROJECT                                                              SECTION 6C — PAGE 126 of 178



6C.5.25.3            Speech Browser Platform System Architecture

Figure 4 shows the components for a VoiceXML system. The integrated platform receives
VoiceXML and CCXML pages from a Web VXML/CCXML document server.




                                         Phone




                               Call Control Manager
                                 Dialog Manager
                                                            Forms
                      Voice                                 Interpreter       Text
                                     VXML                   Algorithm
                      Rec.           Parser                                    To
                                                                             Speech
             voice
                               Process   Collect   Select     Initialize
   Audi                        Phase     Phase     Phase      Phase                          Audio
     o        DTMF                                                                           Output
   Input               DTMF                                                  audio
                        Rec.                                                 player




                         Figure 6C.4 VoiceXML Components

The Speech Browser has to execute the CCXML and VoiceXML pages to provide the
speech service to the caller connected over the telephone network (PSTN or VoIP). The
Speech Browser Platform has to logically consist of four (4) parts:
   1. Main process and operations, administration, and maintenance system:
      collection of tools responsible for system management and error reporting.
   2. VoiceXML and CCXML engines: interpret the VoiceXML and CCXML markup
      and calls into the implementation platform to render the markup.
   3. Speech Browser Platform: provides the high-level services necessary for the
      system to run, including the recognition engine, prompt engine, Automated
      Speech Recognition (ASR), Text-To-Speech (TTS), Internet fetch library, and
      ECMAScript engine.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                      MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 127 of 178



   4. Telephony and base services: base operating system services and telephony
      services needed to receive phone calls. It must support VoIP, T1, PRI, and
      Analog.

6C.5.25.4             Speech Browser Platform Components Requirements
                                                                                                      Bidder
Requirement
                                            Requirement                                   State Use   Agrees
Number
                                                                                                      (Y/N)
   781        The Speech Browser Platform must include a CCXML Engine that                SUPP176
              interprets all CCXML markup and acts as the main control loop.
   782        The Speech Browser Platform must include an XML Parser (SAX and             SUPP177
              DOM).
   783        The Speech Browser Platform must provide an Internet Interface that         SUPP178
              provides access to application documents via http:// access, as well as
              support for posting data back to the Web document server.
   784        The Speech Browser Platform must include an ECMAScript                      SUPP179
              (JavaScript) engine.
   785        The Speech Browser Platform must include a logging interface that is        SUPP180
              used to report errors, events, and diagnostic messages to system
              operators.
   786        The Speech Browser Platform must include a Recognizer that                  SUPP181
              provides the grammar management and recognition services as
              required by the VoiceXML specification, including dynamic grammar
              construction and grammar enabling. It obtains caller input via the
              telephony services.
   787        The Speech Browser Platform must include a Prompt Interface that            SUPP182
              provides complete prompting services, including the ability to play
              "filler" audio in order to support fetch audio. It must handle recorded
              audio (specified by URI) and provide text-to-speech services, passing
              the returned audio to the telephony services for playback.
   788        The Speech Browser Platform must include a Telephony Interface that         SUPP183
              provides call control services, including the ability to transfer and
              disconnect calls as well as delivering telephony events.
   789        The Speech Browser Platform must include an Object Interface that           SUPP184
              provides access to objects, platform defined extensions to the
              VoiceXML language that are accessed through the object tag.
   790        The Speech Browser Platform must support native VoIP interface.             SUPP185
   791        The Speech Browser Platform must support CTI. This includes, but is         SUPP186
              not limited to, the automatic invocation of the appropriate application
              on a CSR desktop, populated with data collected from the IVR.
   792        The Speech Browser Platform must support multi-lingual Automated            SUPP187
              Speech Recognition (ASR) / Text-to-Speech (TTS) for at least the
              English and Spanish languages.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 128 of 178



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        IVR must support Universal Discovery Description and Integration           SUPP193
              (UDDI) .



6C.5.25.6             IVR System Architecture Requirements – Other CNNPAU
                                                                                                     Bidder
Requirement
                                           Requirement                                   State Use   Agrees
Number
                                                                                                     (Y/N)
   798        Each IVR tier must implement load balanced clusters with hot failover.     SUPP200
   799        Each IVR tier must have the capability to dynamically add and remove       SUPP201
              servers to/from clusters.
   800        Each IVR layer must provide ―Drain‖ capability to softly remove a          SUPP202
              server from a cluster.
   801        The IVR and application system must support caching of meta-data           SUPP203
              and data at any layer.
   802        The IVR and application system must support Concurrent                     SUPP204
              Asynchronous HTTP and SOAP requests.
   803        The IVR tiers must support Load Balancing.                                 SUPP205
   804        The IVR System must support development of presentation &                  SUPP206
              application logic using C# and XML.
   805        The IVR system must run on the MS IIS - ASP.NET platform.                  SUPP207
   806        The IVR system must allow use of the latest version (at the time of        SUPP208
              contract award) of Microsoft's Visual Studio to assist EDD in rapid
              development, change, debugging, and testing of VoiceXML and
              CCXML documents, JavaScript‘s, and Web Services for the IVR
              system.
   807        The Speech Browser Platform has to provide Intelligent Call Progress       SUPP209
              Analysis.
   808        The IVR system has to have an interface to EDD operation                   SUPP210
              management systems.
   809        Equipment must utilize Multi-Protocol Label Switching (MPLS) or must       SUPP211
              be field-upgradeable to use MPLS.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                               MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 129 of 178



6C.5.26       System Security Requirements

6C.5.26.1              UCD Security Requirements
                                                                                                       Bidder
Requirement
                                            Requirement                                    State Use   Agrees
Number
                                                                                                       (Y/N)
   810        The UCD system must provide the ability to generate an audit report          SUPP27
              for all records and transactions, and must include the ability to filter
              data by a user-specified date range.
   811        The UCD system must provide audit-tracking reports for user access           SUPP28
              and usage logs. These reports must include the ability to filter data by
              a user-specified date range.
   812        Installation and operation of hardware and software for the UCD              SUPP44
              system must comply with security policies of the Department of
              Technology Services and the Employment Development Department
              (See the Bidders' Library).
   813        Equipment located inside firewalls maintained by the Department of           SUPP45
              General Services, the DTS Data Center and the Employment
              Development Department must only communicate outside the UCD
              system through the existing firewalls.
   814        UCD equipment located outside of the firewalls mentioned above must          SUPP46
              be secured by firewalls and/or screening routers that are approved by
              EDD.
   815        The UCD system will be implemented with a security infrastructure            SUPP47
              and tools for protection of programs and data from unauthorized
              access attempts, as well as security breaches.
   816        The UCD system must leverage existing security infrastructure,               SUPP48
              including network security provisions within EDD.
   817        The UCD system must provide security audit and security audit                SUPP49
              management capabilities for the system administrator.
   818        The UCD system must provide multiple levels of security for system           SUPP50
              administrators based on appropriate use of the UCD system.
   819        The UCD system must include security logs (the facility to log and           SUPP51
              audit all security events) that are separate from the transaction logs
              (the facility to log and audit all operations, changes to data, service
              requests, interactions, and messages).
   820        Any equipment administered by a non-EDD entity as a part of the UCD          SUPP52
              must be separated from the EDD network and other EDD equipment
              using firewalls that will be provided by the Contractor; i.e., the UCD
              must be ―sandboxed‖ so the EDD network and production systems are
              separated from external users.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 130 of 178



6C.5.26.2             User Security (Callers) Requirements
                                                                                                    Bidder
Requirement
                                            Requirement                                 State Use   Agrees
Number
                                                                                                    (Y/N)
   821        The UCD system must provide lock-out capability for a configurable        FCTN852
              time interval after a configurable number of unsuccessful sign-on
              attempts by the Caller.
   822        The UCD system must refer Callers who are unsuccessful in logging         FCTN853
              on to the UCD to an agent.
   823        Caller access to the Continued Claim subsystem and the UI                  IFACE4
              subsystem (for UI claimants) must be controlled by an
              authentication/authorization system. The Contractor must propose an
              alternative authentication/authorization system for use by both
              CCNPAU and CCR that is approved by EDD as meeting its security
              requirements.



6C.5.26.3             User Security (EDD Staff) Requirements
                                                                                                    Bidder
Requirement
                                            Requirement                                 State Use   Agrees
Number
                                                                                                    (Y/N)
   824        Staff of EDD must log-on to the UCD using a unique personal               FCTN854
              identification number and password.
   825        The UCD system must provide lock-out capability after a configurable      FCTN855
              number of unsuccessful sign-on attempts by the user.
   826        The UCD system must include a facility for maintaining personal           SUPP53
              identification numbers on staff, associating those identification
              numbers with the Skills-Based Routing system, and managing secure
              log-on for agents and other EDD staff using the UCD system.
   827        The UCD system must implement existing security infrastructure to         SUPP54
              control and administer multiple levels of user access and privileges.
   828        The UCD system must provide the ability to create and assign user         SUPP55
              IDs and passwords in accordance with the ISO Access Control Policy
              that is available in the Bidders' Library.



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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                              MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 131 of 178


                                                                                                   Bidder
Requirement
                                            Requirement                                State Use   Agrees
Number
                                                                                                   (Y/N)
   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 have the capability to support Secure Socket Layer       SUPP196
              (SSL) and Transport 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        The System‘s Speech Browser Platform must have the capability to         SUPP198
              provide Call Recording.
   834        The System must implement Single Sign-On (SSO) for callers and           SUPP199
              should not require callers to enter additional credentials to obtain
              services.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                             MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                      RFP OSI 7100-181
UIMOD PROJECT                                          SECTION 6C — PAGE 132 of 178



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, Internet 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.


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                     MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                        RFP OSI 7100-181
UIMOD PROJECT                                            SECTION 6C — PAGE 133 of 178




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 Internet 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.


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                       MARCH 23, 2007
  OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
  UIMOD PROJECT                                                   SECTION 6C — PAGE 134 of 178



      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




  0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
  OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
  UIMOD PROJECT                                                   SECTION 6C — PAGE 135 of 178



   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.
                The EAO is undertaking several               Potential Contractors will need to review, leverage,
Enterprise
                architecture definition efforts including:   and comply with these architectures and their
Architecture
                Applications / SOA, Identity                 related product selections, infrastructures, and
Projects
                Management / Privacy, Security / Risk        processes. The architecture information will be
(various)
                Management, Network /                        available through a Bidders‘ Library.
                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.




  0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                    RFP OSI 7100-181
UIMOD PROJECT                                        SECTION 6C — PAGE 136 of 178



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 Internet 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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                          RFP OSI 7100-181
UIMOD PROJECT                                              SECTION 6C — PAGE 137 of 178



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 Internet certification
utilization rates. Only one State has eliminated paper certification forms completely. (The
EDD does not plan on eliminating paper certification.) Initially, Internet 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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                            MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 138 of 178


                                                                                                       Bidder
Requirement
                                           Requirement                                     State Use   Agrees
Number
                                                                                                       (Y/N)
   839        The initial production configuration must be able to accommodate 1.2         SUPP343
              million Internet 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 Internet.
   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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 139 of 178




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 Internet 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




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                           MARCH 23, 2007
   OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
   UIMOD PROJECT                                                   SECTION 6C — PAGE 140 of 178



   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%



   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         The database server must be field-upgradeable by enabling or adding         SUPP338
                   CPUs without replacement of any component parts.
       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 have the capability of taking any individual                SUPP851
                   component of the 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.




   0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 141 of 178



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
              Internet and IVR users 24 hours a day, seven (7) days a week.
   857        The availability of the end user reporting environment must be the          SUPP357
              same as the on-line transaction processing environment.



In addition to providing acceptable response time to EDD customers (Internet 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 Internet (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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 142 of 178


                                                                                                     Bidder
Requirement
                                          Requirement                                    State Use   Agrees
Number
                                                                                                     (Y/N)
   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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                               MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 143 of 178



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, also contained in the Bidders Library.



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 internet.

                                                                                                     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 Internet 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 Internet users     SUPP367
              for identity management.
   869        Intranet users must use Integrated Windows Authentication for smart        SUPP368
              client and browser.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                               MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 144 of 178


                                                                                                           Bidder
Requirement
                                             Requirement                                       State Use   Agrees
Number
                                                                                                           (Y/N)
   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 Internet 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        The self-registration facility must be extensible so that new                    SUPP763
              authentication factors can be added.
   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        A self-registration facility must support the capability of requiring a user     SUPP767
              to enter a secondary ―password‖ to be used as a logical confirmation
              on critical e-forms.
   879        The self-registration facility must record the user IP address and other         SUPP768
              characteristics of the PC used for registration, and have the capability
              to 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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                     MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 145 of 178



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. (The Identity Provider facility
              must reside on a dedicated server on a secure and dedicated sub-
              net.)
   883        The Identity Provider facility must support a redirection of HTTPS            SUPP770
              requests by any registered EDD Web Application to the Identity
              Provider facility.
   884        Identity Provider facility must have Web Services and Web Form                SUPP771
              interfaces for self-registration, identity management and
              authentication.
   885        The Identity Provider facility must support or be extensible for future       SUPP772
              support of WS-Federation and SAML 2+ standards.
   886        The Identity Provider facility must support strong authentication via         SUPP773
              email, SMS to mobile phone, client's primary devices identity/address,
              and questions/answers.
   887        The Identity Provider facility must support administrator specified           SUPP774
              LDAP or Active Directory or DBMS for maintaining
              identities/credentials.
   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.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 146 of 178


                                                                                                         Bidder
Requirement
                                             Requirement                                     State Use   Agrees
Number
                                                                                                         (Y/N)
   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, internet 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.
   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        The Identity Provider facility must provide authentication and                 SUPP859
              authorization services fro multiple channels, including but not limited
              to, external (citizen) internet users, internal (EDD) internet users,
              external and internal systems requesting interface access, and IVR
              users.
   903        The Identity Provider facility must support mechanisms to prevent              SUPP860
              software robots logins and registrations.
   904        The Identity Provider must support configurable options for federated          SUPP861
              Identity with DMV using SAMLv2.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                   MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 147 of 178



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.
   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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                   MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 148 of 178



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, Internet, 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.



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.

0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 149 of 178


                                                                                                      Bidder
Requirement
                                            Requirement                                   State Use   Agrees
Number
                                                                                                      (Y/N)
   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.
   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.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 150 of 178


                                                                                                          Bidder
Requirement
                                             Requirement                                      State Use   Agrees
Number
                                                                                                          (Y/N)
   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.
   946        The SSN and other confidential information must be stored as a                  SUPP408
              confidential attribute in encrypted form using AES or stronger current
              Federal encryption standards, and may use SHA512 hashing for
              confidential data, which does not have to be decrypted. 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 Internet.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                    MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 151 of 178


                                                                                                 Bidder
Requirement
                                           Requirement                               State Use   Agrees
Number
                                                                                                 (Y/N)
   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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                           MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                 RFP OSI 7100-181
UIMOD PROJECT                                                     SECTION 6C — PAGE 152 of 178




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 & data audit components must provide                 SUPP805
              functions to return all versions for any data.
   965        The CCR System data access & data audit components must provide                 SUPP806
              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).

0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                    MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 153 of 178


                                                                                                      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.



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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 154 of 178


                                                                                                   Bidder
Requirement
                                            Requirement                                State Use   Agrees
Number
                                                                                                   (Y/N)
   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,
                     Web Form Application Component invocation,
                     Calls transfers/connects,
                     IVR dialog with user, and
                     IVR Voice Pages invocations (Web SALT or VoiceXML).




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                             MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 155 of 178


                                                                                                        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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 156 of 178



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.

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 & 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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                             MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 157 of 178


                                                                                                        Bidder
Requirement
                                            Requirement                                     State Use   Agrees
Number
                                                                                                        (Y/N)
   984        The CCR System security logging records must have a standard                  SUPP826
              header, and the list of captured data fields must be extendable. The
              list of data fields must include, but not be limited to, 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 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.
   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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 158 of 178



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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 159 of 178



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       All transactional data must be replicated and/or transformed to         SUPP488
              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.

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.


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                            MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 160 of 178


                                                                                                        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).
   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 capability to create new                  SUPP505
              instances (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.


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                  MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 161 of 178


                                                                                                   Bidder
Requirement
                                           Requirement                                 State Use   Agrees
Number
                                                                                                   (Y/N)
   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, configs, 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
   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.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                             MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 162 of 178



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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 163 of 178



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 info 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.


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 164 of 178


                                                                                                       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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 165 of 178



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 contained in the Bidders' Library.
   1059       The System must support the two most recent versions of popular             SUPP553
              Internet 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 Internet 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 internet 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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                           RFP OSI 7100-181
UIMOD PROJECT                                               SECTION 6C — PAGE 166 of 178



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



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                           MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 167 of 178


                                                                                                     Bidder
Requirement
                                            Requirement                                  State Use   Agrees
Number
                                                                                                     (Y/N)
   1077       The CCR System must use MSMQ or WMQ for reliable asynchronous              SUPP573
              messaging.
   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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                               MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 168 of 178


                                                                                                     Bidder
Requirement
                                           Requirement                                   State Use   Agrees
Number
                                                                                                     (Y/N)
   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.
   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).

0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                               MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 169 of 178


                                                                                                       Bidder
Requirement
                                            Requirement                                    State Use   Agrees
Number
                                                                                                       (Y/N)
   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.
   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.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 170 of 178


                                                                                                      Bidder
Requirement
                                            Requirement                                   State Use   Agrees
Number
                                                                                                      (Y/N)
   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
   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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                                RFP OSI 7100-181
UIMOD PROJECT                                                    SECTION 6C — PAGE 171 of 178


                                                                                                           Bidder
Requirement
                                             Requirement                                       State Use   Agrees
Number
                                                                                                           (Y/N)
   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.
   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 capability to manage the itinerary (how the                SUPP749
              inputs 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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                     MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                               RFP OSI 7100-181
UIMOD PROJECT                                                   SECTION 6C — PAGE 172 of 178


                                                                                                       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.



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
              internet 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 have the capability to allow messages, titles,           FCTN1295
              and labels shared by the IVR, the internet applications, and system-
              generated, paper-based forms to be updated from a common source
              so that a single change may automatically update all three channels.


0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 173 of 178


                                                                                                       Bidder
Requirement
                                            Requirement                                    State Use   Agrees
Number
                                                                                                       (Y/N)
   1156       The IVR and CCR System must have the capability to allow                     FCTN1296
              messages, titles, and labels shared by the IVR, the internet
              applications, and paper-based forms to be maintained in 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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                       RFP OSI 7100-181
UIMOD PROJECT                                           SECTION 6C — PAGE 174 of 178



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, & 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 shouldn‘t 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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                      MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 175 of 178



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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                             RFP OSI 7100-181
UIMOD PROJECT                                                 SECTION 6C — PAGE 176 of 178



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 & 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.



0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                 MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                              RFP OSI 7100-181
UIMOD PROJECT                                                  SECTION 6C — PAGE 177 of 178


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 versioning capabilities for 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).




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                                MARCH 23, 2007
OFFICE OF SYSTEMS INTEGRATION                                            RFP OSI 7100-181
UIMOD PROJECT                                                SECTION 6C — PAGE 178 of 178



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 & 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.




0074D5A5-617A-4CE3-91B8-4E162E2964D1.DOC                                              MARCH 23, 2007

								
To top