Summary

Document Sample
Summary Powered By Docstoc
					Ohio Department of Development (ODOD)


   Community Development Division (CDD)

Ohio Community and Energy Assistance Network
                 (OCEAN)


      Technical Requirements Document




                  May 26, 2012
                                                  Table of Contents

1 Summary ...................................................................................................................................... 1

2 Common Functionality.................................................................................................................. 2

3 System Wide Requirements ......................................................................................................... 4

   3.1 General Requirements: .......................................................................................................... 4

   3.2 Basic Design Requirements: ................................................................................................. 4

      3.2.1       Interaction with the Agencies ....................................................................................... 4

      3.2.2       Interaction with other State of Ohio Departments and Agencies ................................. 4

      3.2.3       User friendly ................................................................................................................. 4

      3.2.4       Accessibility.................................................................................................................. 5

      3.2.5       Screen layout design.................................................................................................... 5

      3.2.6       Number of users........................................................................................................... 6

      3.2.7       System Access – Login, User name, Passwords ........................................................ 6

      3.2.8       Electronic Signatures ................................................................................................... 7

      3.2.9       Archive of data ............................................................................................................. 7

      3.2.10 Quality control .............................................................................................................. 7

      3.2.11 Basic Presentation Requirements:............................................................................... 8

      3.2.12 Contingency Design ..................................................................................................... 9

      3.2.13 Site Search Capabilities ............................................................................................... 9

      3.2.14 Pertinent Information notification ............................................................................... 10

   3.3 Basic Application Requirements: ......................................................................................... 11

      3.3.1       Application processing requirements ......................................................................... 11

      3.3.2       Application Printing – Print Friendly ........................................................................... 11

      3.3.3       Partial Information Entry and Save feature ................................................................ 11


                                                                    2 of 39
  3.3.4        Step into a Process feature ........................................................................................ 11

  3.3.5        Common Notes for each Account .............................................................................. 11

  3.3.6        Duplicate Form Submissions ..................................................................................... 12

  3.3.7        Global date and time frame changes ......................................................................... 12

3.4 User Support Functions ....................................................................................................... 12

  3.4.1        General ...................................................................................................................... 12

  3.4.2        IVR Support ................................................................................................................ 12

  3.4.3        Help Information - General ......................................................................................... 13

  3.4.4        Screen Design ............................................................................................................ 13

  3.4.5        System Help ............................................................................................................... 13

  3.4.6        On-the-job instruction and performance support ....................................................... 14

  3.4.7        Documentation and Instructions ................................................................................ 14

  3.4.8        Context Sensitive Help ............................................................................................... 14

  3.4.9        “How-Do-I” Instructions .............................................................................................. 14

  3.4.10 Self Help or Browse by Subject Help ......................................................................... 15

  3.4.11 FAQ’s section ............................................................................................................. 16

3.5 Current Staff, Activities, Projected Concurrency, and Traffic Patterns ................................ 16

  3.5.1        Location and Staff ...................................................................................................... 16

  3.5.2        Demographics ............................................................................................................ 16

3.6 Combined Energy Assistance Application Processing ........................................................ 16

  3.6.1        General ...................................................................................................................... 16

  3.6.2        Capture application data ............................................................................................ 17

  3.6.3        Importing and Exporting Data .................................................................................... 17

3.7 Reports ................................................................................................................................ 18

  3.7.1        General ...................................................................................................................... 18


                                                                 3 of 39
     3.7.2       Frequency .................................................................................................................. 18

     3.7.3       Report display ............................................................................................................ 19

     3.7.4       Information sorting and filtering .................................................................................. 19

4 Technology Architecture Requirements ..................................................................................... 20

  4.1 OCEAN Hardware Platform ................................................................................................. 20

  4.2 OCEAN Software Platform .................................................................................................. 20

  4.3 Agency Platform .................................................................................................................. 20

5 Performance and Operations Requirements ............................................................................. 20

  5.1 Performance Requirements ................................................................................................. 20

     5.1.1       Availability .................................................................................................................. 20

     5.1.2       Throughput ................................................................................................................. 21

     5.1.3       Response time (from click to show) ........................................................................... 21

     5.1.4       Load Capacity ............................................................................................................ 21

  5.2 Operations Requirements .................................................................................................... 21

     5.2.1       Operation by ODOD ................................................................................................... 21

6 Security and Sustainability Requirements ................................................................................. 22

  6.1 General ................................................................................................................................ 22

     6.1.1       Portal Access ............................................................................................................. 22

     6.1.2       Communications Security .......................................................................................... 23

     6.1.3       Documentation ........................................................................................................... 23

     6.1.4       Systems Architecture ................................................................................................. 23

     6.1.5       Designation of Roles & Access Rights....................................................................... 23

     6.1.6       Application Security.................................................................................................... 25

     6.1.7       Accountability ............................................................................................................. 27

     6.1.8       Auditing ...................................................................................................................... 28


                                                                   4 of 39
      6.1.9       Object Reuse ............................................................................................................. 30

      6.1.10 Accuracy .................................................................................................................... 30

      6.1.11 Data Exchange........................................................................................................... 31

   6.2 Reliability.............................................................................................................................. 31

      6.2.1       Real-time Failover ...................................................................................................... 31

      6.2.2       Backup & Storage ...................................................................................................... 32

      6.2.3       Data Integrity .............................................................................................................. 32

      6.2.4       Redundancy ............................................................................................................... 32

   6.3 Intrusion Detection & Dispensation ..................................................................................... 32

   6.4 System Diagnostics ............................................................................................................. 33

7 Standards ................................................................................................................................... 33

   7.1 ODOD IT Platform Standards .............................................................................................. 33

   7.2 State of Ohio Technology Security Standards..................................................................... 34




                                                                    5 of 39
                 Ohio Community and Energy Assistance Network (OCEAN)

                          Systems Requirements Concept Document

                                  “To-Be” Executive Overview


1 Summary

The Ohio Department of Development (ODOD) desires to implement a new system to process
and deliver the energy and community service assistance programs to Ohioans who request aid.
Specifically they desire OCEAN to provide for effective and efficient entry and acceptance of an
applicant’s information, determination of an applicant’s eligibility, integration with the financial
systems that disperse aid, and provide support to assist employees to meet various legal
obligations through web enabled applications and databases. OCEAN includes the following
assistance programs:
             Home Energy Assistance Program (HEAP),
             Emergency Home Energy Assistance Program (E-HEAP),
             Percentage of Income Payment Plan (PIPP),
             Universal Service Fund (USF),
             Community Services Block Grant (CSBG) and related programs,
             Results Oriented Management Accountability (ROMA) and
             Home Weatherization Assistance Program (HWAP).
The Office of Community Services (OCS) and Office of Energy Efficiency (OEE) manage these
programs.

While a current system exists, it is comprised of a paper and automated HEAP application and
software from 7 plus vendors used by the 62 Community Action Agencies and other authorized
providers (here after referred to as Agencies) for HEAP, E-HEAP, PIPP, HWAP, USF, CSBG,
and ROMA processing. At each Agency location, the software products used are often disjointed,
not networked, and require manual steps to consolidate local information for applicants. Collected
data must be entered into multiple software applications within a single Agency in order to offer
assistance from the multiple programs available. The goal of ODOD is to provide an efficient
process for collecting, processing, and sharing data of applicants across the various programs.
The thinking at ODOD is to have a Central Database and eliminate the need to enter an
applicant’s data multiple times. This would also provide the capability to access this data across
and within the Agencies via a Web Portal interface. ODOD and its associated Agencies are
committed to working together with the selected vendor in the design and implementation of
OCEAN to accomplish these goals. ODOD has organized the assistance programs into the
following modules:


        Core Module
                     Client Intake and Client Tracking
        Program Modules
                     Bill Payment Assistance- [Home Energy Assistance Program (HEAP);
                             Emergency Home Energy Assistance Program (E-HEAP);
                             Percentage of Income Payment Plan (PIPP)]




                                               1 of 39
                     Community Services Block Grant (CSBG) and Related Programs; Results
                        Oriented Management Accountability (ROMA)
                     Home Weatherization Assistance Program (HWAP); Universal Services Fund
                        (USF)



To help the reader understand the concepts ODOD envisions for this system, this document
defines the current thinking of OCEAN requirements. This document is not intended to define the
actual requirements or impose design restraints on OCEAN. ODOD thinks the system and
application requirements must be flushed out using appropriate techniques such as JAD sessions
with staff members and other possible users of OCEAN. The following is a summary of the high-
level goals, objectives, and functional requirements for both the common and unique operations.
The following text provides the basic scope definition for this project. When known, this document
provides detailed requirements to aid a vendor in the bidding process. As such, ODOD is open to
suggestions and design alternatives that would improve upon the requirements and design
concepts presented in this document without increasing the cost of the project.


2 Common Functionality

Architecture

The OCEAN system is envisioned to be a web based application and database used to capture
and store records and information associated with a given applicant involved in any of the
assistance programs. This includes maintaining a complete audit trail of all information captured,
stored and modified in the system with a reason, when, and who entered or changed the
information.

The OCEAN system is to be scaleable in design so that as Agencies and numbers of applicants
for assistance programs increase, the system can be expanded with relative ease and little
expense.

OCEAN is to also be developed using Microsoft products, the preferred choice of ODOD.

OCEAN is expected to build upon the recent project by ODOD to covert their HEAP database
from DB2 and FoxPro to Microsoft SQL 2000. This database, called HEAPSYS, provides data
capture for HEAP applicants, interfaces to accounting systems, utilities, the State Auditors Office,
and determines eligibility of applicants for HEAP benefits.

Workflow

OCEAN will utilize a workflow throughout its operation that includes on-screen forms that various
ODOD and Agency staff will use to enter, edit, and display information in OCEAN. It is envisioned
that this workflow will accommodate the capture and use of data via form entry, automatic
processes such as initial eligibility determination, and provide real-time access to the data via
high-speed data networks. Where appropriate, batch processing of applicant data may be used.
The forms and reports used by the Agencies will be hosted at the ODOD computing center to
provide standardization of software used by the Agencies, to allow sharing of data, and to
eliminate the need to enter the same information into multiple application programs.

Accounting/Finance

OCEAN will be capable of supporting transactions for about 450,000 plus applications each year
with a minimum of 10 years of historical data online. OCEAN will continue to provide interfaces to
ODOD financial systems for managing Assistance Program Budgets and the State Auditors


                                              2 of 39
Office for generation of Warrants and Vouchers issued to program applicants and utility providers.
OCEAN will also continue to provide interfaces to the Regulated Utility Companies for registration
of PIPP customers and authorization of direct payment of benefits where appropriate.

Portal

It is envisioned that OCEAN will be a “Portal-Like” environment. The ODOD and Agency staff will
be able to logon to the system via Microsoft IE 6.0 Internet browser and gain access using a
single user name and password assigned or established for that individual staff member. Once a
staff member is logged-on, they will have access to all of their approved functionality for any
authorized OCEAN application. This log-on will also provide access to data from other
informational sources (optional module – Electronic Sources to Verify Applicant Supplied
Information), once there is an agreement established with these agencies. This super password,
for each individual staff member, will be the key chain of associated passwords and user names
for the various systems they need to access. See Section 6.1.5 – Designation of Roles and
Access Rights for detailed discussion.

The system will provide each user with the ability to personalize their experience by seeing only
the information they have an interest in. OCEAN must provide a means to set up their
environment, determine delivery choices, and select user support options. Users, with the
appropriate authorization, will be able to enter and edit all information for an applicant’s account,
establish bookmarks for work in progress, save work in progress, and perform sophisticated
global searches of stored information. In determining their delivery choices, every ODOD and
Agency staff member will be provided a Message Box on the system where notices and
information are provided. However, the user can choose an alternate delivery method (i.e., paper)
or have an email notification sent whenever information is posted to their message box.

Reporting

The system will provide a wide variety of reports to support reporting requirements across ODOD
and Agency staff. This includes providing periodic (e.g., daily, weekly, monthly, quarterly,
annually reports), or reports based on date ranges as specified by ODOD and Agency staff, and
ad hoc reports. This includes allowing ODOD and Agency staff to select the types and summaries
of information desired. OCEAN will provide these reports for all organizational entities within
ODOD and authorized Agencies.

Data Conversion

All information currently in the existing system shall be converted to the OCEAN system. This
includes all historical information and information entered during the system implementation. The
system will provide an ongoing capability to accept information from ODOD, Agencies and the
regulated utility companies via file transfer. OCEAN will have the capability to convert and enter
this information into its database and associate the data with the appropriate account to provide a
complete and accurate record for an applicant.

Case Management

OCEAN will have the capability to perform case management by tracking all information
associated with an account including, but not limited to services, calls, meetings, documents
received, correspondence sent, and changes to an applicant’s accounts.

The tracking of information associated with an applicant’s account from inception will provide
ODOD and Agency staffs with the capability to retrieve, edit, and adjust an applicant’s information
as needed. The retrieval of an applicant’s information may be, at a minimum, by date, applicant’s
name, SSN, or Agency staff member who processed the information.



                                               3 of 39
3 System Wide Requirements

 3.1 General Requirements:

     The overall design and implementation of this application and system must:

                  Use standard conventions, understandable to any user;
                  Allow all users to perform all tasks accurately and completely with limited
                   training;
                  Reduce the time and effort required for a ODOD and Agency staff member to
                   file an applicant’s request for assistance;
                  Adhere to all ODOD policies for processing new and existing applicant
                   accounts;
                  Adhere to all State and Federal Laws governing the assistance programs;

 3.2 Basic Design Requirements:

   3.2.1   Interaction with the Agencies

           The OCEAN application, for authorized Agency staff, will be accessible from the
           ODOD web site.


   3.2.2   Interaction with other State of Ohio Departments and Agencies

           ODOD currently exchanges data with the State of Ohio Auditors Office to print and
           reconcile warrants, vouchers, and direct deposits. This interface uses Electronic
           Data Interchange standards. The OCEAN must continue to support this interface
           and others that currently exist.

           ODOD has proposed an optional module for exchanging with other State of Ohio
           Department and Agency data. This interface will be used only for authorized State of
           Ohio staff, such as the State of Ohio Department of Jobs and Family Services
           (ODJFS - Unemployment) and other agencies, who agree to exchange information. It
           will be accessible from the ODOD web site.


   3.2.3   User friendly

           The OCEAN application must be user friendly by following the best practices of
           Electronic Performance Support Systems (EPSS). By this, ODOD means the
           application and system must maximize the capability for users, with limited
           knowledge, to enter information without error as well as provide experienced users
           with shortcuts and options to allow them to function at their maximum capacity.

           The EPSS design must also provide just-in-time support, particularly for exceptional
           and complex queries; and the vendor must ensure that the EPSS is both easy-to-use
           and extremely responsive. The design must allow users the ability to reach any
           information in just three clicks. Additionally, there must be a bookmark feature in the
           system itself, so that the user can get to the information and support they require with
           just one click. The size of data files must be kept to an absolute minimum to speed



                                             4 of 39
        up retrieval, and the EPSS must use a structured format in the design of the
        information to ensure total clarity.

               The system must allow the user to access appropriate information, tools,
                training, and expert advice at the very moment it is needed and at the place it
                is needed.
               The system must allow the user to access information, tools, training, and
                expert advice, which are specific to the task and the situation of the user.
               The system must allow the user to access only the specific information, tools,
                training, and expert advice needed at that instant, which means that
                irrelevant information must be excluded or hidden.
               The system must allow the user to access user-defined or customized tools,
                which can provide automation of selected work activities.
               The system must allow the user to get or consult expert advice, which
                should:
                    o   Structure problems and/or support in decisions, analyses, and
                        diagnosis;
                    o   Be integrated with the other components of the EPSS;
                    o   Be correct and not distract the user by asking the wrong questions or
                        give the wrong support.
               The structure of an EPSS must be customizable for different groups of end-
                users and must reflect their work situation and needs
               The screen design must be consistently organized according to a principle(s)
                of sequence (e.g. importance, frequency of use, topical, chronological, etc.)
                with important or frequently used information placed on top of each page

3.2.4   Accessibility

        OCEAN must be designed to be accessible to ODOD and Agency staff with
        disabilities. As such, the OCEAN system must meet the following accessibility
        requirements:

               Comply with the Rehabilitation Act, section 508
               Be Bobby Approved, see http://www.watchfire.com/solutions/accessibility.asp
               Meet Level A conformance, W3C WAI-A web content accessibility guideline
                1.0

3.2.5   Screen layout design

        ODOD and the Agencies use Microsoft products and this will allow the Portal to be
        developed using a screen resolution of 1024 x 768 pixels.

        However, it should be noted that Portal interfaces to other Ohio agencies may require
        a lower screen resolution, as several State agencies support resolutions of 640 x
        480. This lower screen resolution may also be needed to support Federal
        Regulations for Handicap access to the system, see Section 3.2.4 Accessibility.




                                         5 of 39
3.2.6   Number of users

  3.2.6.1   Support

            Upon initial deployment, OCEAN must support a minimum of 250 simultaneous
            users working concurrently on line. Once OCEAN is fully deployed the number of
            simultaneous users is expected to be about 1000 users.


3.2.7   System Access – Login, User name, Passwords

  3.2.7.1   General - Ohio requirements

            The system must follow the State of Ohio Guidelines that requires users to login
            and set the parameters of the login function. The users of the OCEAN application
            may include:

                       ODOD staff
                       Agency staff
                       Other State of Ohio Employees, as provided for by agreements with
                        ODOD and other Ohio agencies.

  3.2.7.2   Single sign-on

            The system must provide a single sign-on feature for each staff member to the
            OCEAN application. In other words, an ODOD and Agency staff members must
            be able to sign on to the OCEAN application and have access to OCEAN and
            any related applications or databases without having to separately sign-on to
            those applications or databases.


  3.2.7.3   Sign-on to the OCEAN application

            OCEAN must allow any users to access the application’s home page and any of
            the support and help features without requiring an additional sign-on to access
            these features.

            To enter or view any OCEAN data, OCEAN must require a user to enter a
            password and user name in accordance with the Information Technology
            Security Architecture for the State of Ohio
            (http://www.state.oh.us/das/dcs/opp/pdfs_other/SEC-V1.pdf).

                       The user name must identify the person using the application.
                       The user name must determine the accessibility to view and/or edit
                        information within OCEAN, function by function.

  3.2.7.4   Controlled Access to the OCEAN application

            The OCEAN must be able to distinguish between authorized and unauthorized
            computer systems attempting to access the OCEAN applications. Only those
            computer systems and users authorized to use the OCEAN application will be
            allowed access. This capability will not restrict Agencies from setting up



                                        6 of 39
            temporary Assistance Centers so long as the computers and users at the center
            have authorization to OCEAN.


3.2.8   Electronic Signatures

        OCEAN must provide the capability to electronically sign (digital signature) forms and
        other electronic documents within the requirements established by Federal and State
        of Ohio law. This is a possible future enhancement that the system must
        accommodate.

        OCEAN must be compliant with DAS - Computer Services Division Administrative
        Rules for use of Electronic Signatures:

                http://www.state.oh.us/das/dcs/opp/AdministrativeRules.htm


3.2.9   Archive of data

  3.2.9.1   General

        OCEAN must maintain an archive of all data entered by ODOD and Agency staff and
        any other authorized users.

        The system must retain all records in accordance with the Ohio Record Retention
        Center requirements. (Ohio Revised Code sections 121.07 and 149.34.)


  3.2.9.2   Audit trail and reports

        OCEAN must establish and maintain an audit trail of who, when, the reason, and
        what change was made to any of the system’s data.

        The system must provide, at a minimum, the capability to generate an audit report for
        an applicant’s account and have it include and organize the report by any of the
        following:

                   Chronological date range
                   Type of change made
                   User who made the change
                   Reason for the change
        This audit trail must be maintained online for XXX months/years at which point it may
        be archived in accordance with Ohio Record Retention Center standards or as
        defined by ODOD.


3.2.10 Quality control

        OCEAN must provide a capability to monitor the quality of data entered and
        processed. The quality control functions must include at a minimum the following:



                                         7 of 39
                 Random sampling of work
                 Generation of test cases for testing automatic rule processing
                 Random sampling of the results from any automated process
                 Capability for ODOD technical staff to establish quality metrics for both
                  online and paper processing.
                 Capability for ODOD technical staff to determine the quality of service,
                  such as how quickly or responsive the application is; the accuracy of the
                  response to a user; and the level of the satisfaction of the user.

3.2.11 Basic Presentation Requirements:

 3.2.11.1 “Real-time” processing

          OCEAN must provide “real time” entry, editing and processing of information
          stored in the Central Database. Where appropriate, batch processing of
          applicant data may be used.


 3.2.11.2 Field presentation

          The application must provide limited instructions that can be easily understood
          and provide immediate “real time” feedback to a user upon entry of data into any
          field displayed on screen.

          The applications shall have the same style, look, and feel of the new State of
          Ohio Web site, www.state.oh.us.

          The application shall display data and entry fields consistent with the structure of
          data on the Combined Energy Assistance Application and the CSBG application.


   3.2.11.2.1 Locked fields

              The system must display locked fields in a manner that is different than those
              fields that are available to a user for entry or modification of data.


   3.2.11.2.2 Embedded labels

              The system must display an indicator in each field that identifies that field
              when it is empty. After a user enters any information into a field, the display
              of the field must change and only display the entered data.


   3.2.11.2.3 Edit checks

              The design must allow a user to quickly modify any previously entered
              information based on “real time” system feedback messages. The system
              must not require the user to click a submit button and wait for the system to
              edit check the entire screen and its data.




                                        8 of 39
              OCEAN must display a small, but visible, indicator that changes in “real time”
              when the data being entered must meet specific edit criteria and indicate
              which fields are required.

              For example, the system must perform a “real time” edit check and validation
              of a SSN as the user enters the information. Upon completion of the
              validation process, the application must immediately display, without a visible
              screen refresh, any associated information currently in the system such as
              an applicant name and address.

              The design must require all fields be parsed to prevent known Hacker tricks,
              such as SQL injection.

              All URL arguments must be validated to insure valid values, lengths, etc.

              All text fields must be Spell Checked before updating to the OCEAN
              database. Note there may be exceptions to this test, such as Name and
              Address. Where exceptions exist, spell verification of the application is
              inappropriate.

              ODOD currently uses a set of Code Set Tables to define standard
              abbreviations and values for field entry into the database.


   3.2.11.2.4 Display of data elements

              The system must display all fields in a manner that a user would normally
              expect, such as decimal alignment for monetary amounts, and presented in a
              manner that is easy to read.


3.2.12 Contingency Design

       The system must include contingency design that assists ODOD and Agency staff
       when a problem occurs. This design must follow contingency guidelines to improve
       the site’s performance and increase the satisfaction of ODOD and Agency staff by
       providing them alternative recommendations and/or automatically following
       contingency alternatives. Examples of possible contingencies include:


                 Procedures for performing Intake during communication line outage;


                 Redundant servers and hot swappable disk drives;


                 Modem backup to high speed network communications;


3.2.13 Site Search Capabilities

       OCEAN must include a search function. ODOD views this function important for:




                                       9 of 39
                  Easier Site Navigation – to give our staff a way to quickly find the
                   information they need.
                  Better Control – This capability allows ODOD and Agency staff members
                   to go directly to a screen they desire rather than wade through numerous
                   screens. This feature will reduce the amount of time necessary to review
                   or update critical information on an applicant.

3.2.14 Pertinent Information notification

 3.2.14.1 Pending operations

           OCEAN must display a message upon login to an ODOD agency staff member
           when there is a pending task for them, see Section 3.2.14.2.

           OCEAN must display a message upon login to the user when there is a
           resolution to a pending operation, task, activity, or question. This information
           must be displayed at least once. Examples of pending operations, tasks,
           activities, or questions include but are not limited to:

                      Notification of recent changes to profile information.
                      Notification of changes to applicant data by another Agency or staff
                       member
                      Notification of monthly statement availability

 3.2.14.2 Message Box

           The system must provide the capability for a message box feature. This is the
           preferred method of delivering all information to and from various agencies and
           their staff, collectively and individually.

           This Message Box feature must provide the user with the following information
           including but not limited to:

                      Notification of required actions
                      Reminders
                      Correspondence received
                      Complete list of all messages
               This Message Box feature must provide a capability for a user, at a
               minimum, to:

                      Read all messages
                      Send replies or new messages
                      Receive notification of new messages
                      Set an option to receive an email notification of a new message
                       within their message box. This option must be accomplished with a
                       user preference profile.
                      Use secure email with the capability to:
                            o   Receive information from an other agency, with attachments



                                        10 of 39
                             o    Send confidential information to an other agency, with
                                  attachments
                        Support the use of the capabilities of the IVR system to provide the
                         ability to listen (text to speech) to the messages in their message
                         box.

3.3 Basic Application Requirements:

 3.3.1   Application processing requirements

         ODOD knows that slow load times can deter users and therefore the system must
         load the application pages in less than 5 seconds.


 3.3.2   Application Printing – Print Friendly

         OCEAN must be designed to insure that each online page has a printable format that
         prevents the loss of text from either the left or right margin or any graphic images
         when printed.


 3.3.3   Partial Information Entry and Save feature

         OCEAN must provide the capability for a user to enter partial information on any
         screen, during any process, and save that information.

         For example, the user does not have all of the data required for completing the
         process, the user could opt to stop, log out of the system, obtain the information, log
         back onto the system, and return back to where they left off to complete the process.

         OCEAN must provide the capability to save new or changed data to the Central
         Database upon change of each web form.


 3.3.4   Step into a Process feature

         OCEAN must allow the applicant to go to the beginning of any process to review or
         modify information previously entered.

         For example, when the user returns to where they left off, there would be a
         mechanism to return to an earlier screen of the process without paging through
         multiple screens.


 3.3.5   Common Notes for each Account

         OCEAN must provide ODOD and Agency staff members with the capability to create
         or add information to common notes on an applicant’s account.

         OCEAN must track the date, time, and the user creating or adding text to the
         common note.




                                          11 of 39
         OCEAN must provide ODOD and Agency staff with the capability to view the
         applicant’s common notes in either ascending or descending order by or combination
         of:

                    Date
                    Range of dates
                    Author

 3.3.6   Duplicate Form Submissions

         OCEAN must prevent a form with data or information that adds or removes data from
         being submitted or processed multiple times. Once the application accepts the data
         for an applicant’s account, the system must only allow modification of that information
         and maintain an audit trail of that modification.

           Note: The purpose is to prevent the data from the screen being entered two or
           more times when the user clicks the submit button more than once. This is not
           meant to prevent modification or addition of new pieces of data.

 3.3.7   Global date and time frame changes

         OCEAN must provide ODOD and Agency staff management with the capability to
         change any and all dates and time frames associated with any rule based decisions
         made by the system.


3.4 User Support Functions

 3.4.1   General

         OCEAN must provide support services to the Agencies and their staff. The system’s
         capabilities must provide, as appropriate, full access to the applicant’s account
         information, along with any historical records, to assist in the resolution of issues or
         questions around the submission of an applicant.

         OCEAN must provide a variety of user support and help functions by regular login
         and/or special training login and password such as:

                Viewing a summary of Features and Benefits
                Viewing online “How Do I” instructions
                Viewing reference material that relates to the various energy assistance and
                 CSBG programs.
                Connecting to a training database to explore the application with dummy
                 data.

 3.4.2   IVR Support

         At present, the ODOD operates and maintains an Interactive Voice Response system
         (IVR). This IVR provides authentication and data collection to support the processing
         of business functions that include:



                                           12 of 39
               1) General Information
               2); Application Inquiry
               3). ???????????????
        ODOD may choose to expand the functionality of the current IVR to mirror the
        functionality developed for OCEAN. At the very least, OCEAN must include the
        functionality of the current components as well as those components developed to
        support the requirements of OCEAN as outlined in these documents.

        Additionally, the design of OCEAN must provide the capability to support future IVR
        capabilities. The IVR may end up to be an integral component of OCEAN and it may
        have to support the IVR capabilities to recognize the applicant calling; automatically
        access an applicant’s account; process the applicant’s request; or as needed, route
        the call to the appropriate ODOD and Agency staff member and display the
        applicant’s information on their screen (screen pop.) Thus, the design of OCEAN
        must provide the capability to support and process data exchanges to and from the
        IVR system and integration points to the IVR system to the extent that all of the new
        OCEAN components, such as web pages, popup screens, and data exchange, will
        function in conjunction with the enhanced IVR system upon the implementation of
        OCEAN. This includes the design and development of any needed stored
        procedures, FTP processes, advanced authentication procedures (LDAP), or
        communication handshakes with the IVR system.

        OCEAN must keep a record of all voice and IVR communications with the applicant
        in the applicant’s record to allow the OCS/OEE staff to review all past calls and any
        resolutions.


3.4.3   Help Information - General

        OCEAN must provide several levels of support and Help information to the users of
        OCEAN. The levels of help must range from a basic summary level to very detailed,
        step by step instructions with an example.


3.4.4   Screen Design

        OCEAN must provide access to both contact information and help information on
        every application screen.


3.4.5   System Help

        The system help must be integrated, offer an on-demand access to information,
        provide tools, and provide education and help to a user that enables a high level of
        performance. This must include online:

                   Business procedure information
                   Policy documentation
                   “Just-In-Time” education and help in accordance with industry best
                    practice EPSS formats




                                          13 of 39
3.4.6   On-the-job instruction and performance support

        OCEAN’s design must provide real time on the job support by using an industry best
        practice EPSS (Electronic Performance Support Systems) that includes components
        such as task- and situation-specific information, task-oriented education and help,
        expert advice, customized tools to perform business operations, etc; which should be
        ideally available on demand at any time, any place, and regardless of the situation.


3.4.7   Documentation and Instructions

        All on-line documentation must be produced and available in PDF and/or either
        HTML, DHTML, or XML format.

        There must be instructional information developed and designed for a hard-copy
        guide that contains at a minimum:

               How to log-on,
               How to log-off,
               Basic access requirements,
               Basic filing procedures,
               Instructions on how to navigate OCEAN, and
               An overview of each function of OCEAN

3.4.8   Context Sensitive Help

        The system must provide context sensitive information for each field on each screen
        within the system. This context sensitive help must provide the capability to
        investigate the meaning of unclear terms or actions within the application.


  3.4.8.1   Display of Context Sensitive Help

            The context sensitive help information must be immediately visible to a user upon
            an interactive request by the user.


  3.4.8.2   Detail Explanation

            The context sensitive help must go beyond simply defining the term by providing
            the user with an orientation to the current term or form field as it applies to the
            overall process. Additionally, upon display of the context help information, the
            application must provide the user with the capability to view the related “How-Do-
            I” section or obtain a detailed, in depth explanation.


3.4.9   “How-Do-I” Instructions

        The system must have detailed “How-Do-I” instructions for accomplishing each task
        or process to handle an applicant’s application. This help must include descriptions
        and step-by-step instructions with example screen images.




                                           14 of 39
3.4.10 Self Help or Browse by Subject Help

       OCEAN must provide a list of topics so the user, without having to log into the
       system, can browse by subject matter. Examples include, but are not limited to the
       following:

                  General Information
                  Minimum system requirements
                  Browser supported digital certificates
                  How to use the Customer support
                  Using OCEAN, the basic process (New applicants, prior applicants, etc.)
                  Getting started
                       o   General
                       o   What is needed to begin
                       o   Accessing the OCEAN
                       o   Logging off OCEAN
                       o   Getting assistance
                  Login ID and Password
                       o   Registering Login ID and Password
                       o   Hints for unique Login IDs
                       o   Changing Passwords
                       o   Controlling passwords
                       o   Unable to login
                       o   Forgetting passwords
                       o   Assigning function by passwords
                  Administrative Information
                       o   General
                       o   Laws and Regulations
                       o   Appeals and Waivers
                  Technical issues
                       o   How do I optimize my web site viewing?
                       o   Does my browser support 128-bit encryption?
                       o   Connectivity
                       o   Configurations and Settings
                       o   How do I speed up the load time for web pages?
                       o   How do I protect my password?
                       o   Downloading
                       o   How do I fix Site Not Found error?
                       o   How do I stop getting scripting errors?
                  Internet Explorer issues




                                         15 of 39
 3.4.11 FAQ’s section

         OCEAN must provide a Frequently Asked Questions section that is available without
         having to log into the system. This section must initially include answers to questions
         that ODOD and Agency staff suspect will be commonly asked by users.

         Example of possible questions may include all of the “Browse by Subject” items and
         the following questions:

                    How do I access the OCEAN?
                    How do I get started?
                    How do I establish a user name and password?
                    What do I do if I forget my password?
                    What are the minimum system requirements to OCEAN?
                    How do I change contact information, such as telephone number, email,
                     and mailing address?
                    How do I register a new client?
                    How do I edit the entry for an old client?

3.5 Current Staff, Activities, Projected Concurrency, and Traffic Patterns

 3.5.1   Location and Staff

         ODOD Central staff varies. In the off-season (summer) there are about 52
         employees. In the winter season the number increases to about 102 – all temporary.

         ODOD Central Office is in downtown Columbus in the Riffe Building.

         ODOD’s Data Center is housed in the Riffe Building.

         ODOD agencies have 52 Local (CAA) Offices within the state and 12 authorized
         energy assistance providers. The range of employees in a single agency is 6 to
         100+.


 3.5.2   Demographics

             ODOD agencies serve approximately 450,000 households.


3.6 Combined Energy Assistance Application Processing

 3.6.1   General

         OCEAN must recognize when a transaction involves a new application or that the
         applicant does not already exist in the system and automatically establish an account
         for that applicant or display data residing in the OCEAN database for edit.

             Applicant Matching must include:


                                          16 of 39
               Name Soundex search;
               Nickname search, e.g. Bob for Robert;
               Alias search, e.g. maiden name;
               Social Security Number search;
               Address search, current and/or prior;

3.6.2   Capture application data

        The system must capture all of the data for a new applicant found in the Combined
        Energy Assistance Application, found in Appendix XX.

        The full list of required fields and data formats will be determined during the design
        phase.

        OCEAN must allow an ODOD and Agency staff member to manually enter the data
        for the applicant’s application.

        OCEAN must pre-fill the fields displayed with known data values from the applicant’s
        account and allow a member of the ODOD and Agency staff to edit the values in
        these and the remaining fields.

        At the completion of the data entry, the ODOD staff member must have the ability to
        view, verify, and/or edit the entered data.


3.6.3   Importing and Exporting Data

  3.6.3.1   General

            The OCEAN system will be implemented at the Agencies over a period of time
            meaning not all Agencies will be using OCEAN in the beginning. Therefore,
            OCEAN must support the ability to accept assistance program data from
            Agencies using application software other than OCEAN.

            OCEAN must also support the ability to Export assistance program data from
            OCEAN so that Agencies can have access to OCEAN data. Agencies have also
            requested the ability to download OCEAN data to be used for site specific
            reporting needs.


  3.6.3.2   Receipt Method - Import

            Program data may be provided by these Agencies by electronic media (tape,
            diskette, CD-ROM), FTP, or e-mail attachment. Method used is dependent on
            the Agency, application software used at the Agency, and communications or
            Internet Service Provider (ISP) capability at the Agency (dial-up, high speed).




                                         17 of 39
   3.6.3.3    Transmission Method - Export

              OCEAN data may be provided to the Agencies by electronic media (tape,
              diskette, CD-ROM), FTP, or e-mail attachment. Delivery method will depend on
              the Agency, application software used at the Agency, and communications or
              Internet Service Provider (ISP) capability at the Agency (dial-up, high speed).


   3.6.3.4    Data Format

              The process must provide the user the ability to specify common file types (e.g.
              *.txt, *.csv, *.wrk) and delimiter used (e.g. comma, tab, other) to define the file
              being processed.


   3.6.3.5    Data Validation

              Files must be loaded into a work area where validation and consistency checks
              may be performed and edits made prior to loading into the OCEAN database.
              This process should be automated to the extent possible.


3.7 Reports

 3.7.1   General

         The OCEAN must be capable of generating any report required by the State and
         Federal regulations governing any of the assistance programs. As such, the OCEAN
         must capture the required data the report is based upon, process the data into the
         format required for the reports, and then print the report to the appropriate form,
         paper, or electronic media as required.

         Funding sources other than State and Federal governments also have reporting
         requirements of the Agencies delivering assistance programs. The OCEAN must be
         capable of capturing the appropriate level of detail, process the data, and then print
         the reports necessary to meet the reporting requirements of these additional
         contributors. Specific details shall be determined during the design phase of
         OCEAN.

         The system must provide, at a minimum, all of the reports listed in Appendix XX .

         OCEAN will have the capability to generate reports in either Adobe PDF or Microsoft
         Word formats.


 3.7.2   Frequency

         OCEAN must provide the user with the capability to specify time elements for each
         report. This includes establishing the time period(s) (e.g., daily, weekly, monthly,
         quarterly, annually) or date ranges of the report, schedule automatic periodic runs for
         the report along these time periods or data ranges, and generating ad hoc reports.




                                           18 of 39
        The system must generate on demand or automatically, any standardized report
        necessary to meet government requirements or that of other program contributors.
        The OCEAN must also support generation of ad hoc reports.


3.7.3   Report display

        OCEAN must provide the option to view these reports online; print the reports;
        download the reports in a tab-delimited format for possible use in spreadsheets,
        personal databases, text documents, and presentation software; and send these
        reports electronically via email or as a message to the applicant’s message box.


3.7.4   Information sorting and filtering

        OCEAN must provide the capability for the user to select the types and summaries of
        information desired for each report.

        OCEAN must provide the capability within reports for the user to “Drill Down” to lower
        levels of detail and/or expand the report to include more detailed information.

        Each report must have predefined sorting and filtering rules based on the users
        access rights, but the system must always provide the capability to have the
        information sorted either in ascending or descending order and restricted by specific
        data elements to be identified during the design.

        OCEAN must provide the various users (e.g. external agencies, internal ODOD and
        Agency staff, etc.) with the ability to generate reports relevant to the information they
        need which is both current and/or historical.




                                          19 of 39
4 Technology Architecture Requirements

 4.1 OCEAN Hardware Platform

     The ODOD shall provide the hardware equipment, communications, and operating software
     to support the OCEAN. During the design, the Offeror will determine the computing
     environment necessary to support the OCEAN and make recommendations to the ODOD
     for hardware equipment, communications, and operating software. This architecture is to
     include but not be limited to Servers, Disk Arrays, Backup Recovery Systems, Routers,
     Firewall, and the like. The ODOD will then purchase the required hardware to support the
     OCEAN under their State Term Purchase Contracts with approved vendors.

     ODOD anticipates that computers accessing the OCEAN Portal by ODOD and Agency
     Staff to be using MS Windows XP and MS IE 6.0 browser.

     The architecture of the OCEAN system must be scalable. ODOD plans to bring Agencies
     into the OCEAN system over a period of XX years. Having a scalable computing
     architecture will allow ODOD to spread the cost of hardware to support OCEAN over the
     installation period.

 4.2 OCEAN Software Platform

     The ODOD has expressed a desire to develop the OCEAN using Microsoft products. The
     minimum version level for Microsoft products requested to be used include: MS SQL 2000
     for the Central Database, MS Windows 2000 Server for the operating system, MS .NET
     Framework for the Web development. New Microsoft products may be recommended and
     used for this project.

     Microsoft products are to be patched to the latest Patch and/or Service Pack levels
     released by Microsoft.

     Software and software licenses required to develop and support the OCEAN system will be
     purchased by ODOD through their State Term Purchase Contracts with authorized
     vendors.


 4.3 Agency Platform

     The Agency computers are expected to be running Microsoft Windows XP Professional and
     at a minimum Microsoft IE 6.0 browser.


5 Performance and Operations Requirements

 5.1 Performance Requirements

   5.1.1   Availability

           The system must provide a minimum up-time availability of 99.8% outside of
           scheduled maintenance. As an option, Offeror must propose a solution to increase
           availability to 100%. The Offeror must describe how this will be achieved and what
           assumptions were made.


                                           20 of 39
 5.1.2   Throughput

         The Offeror must state the normal and maximum volumes, response times and
         stations that the proposed architecture will support for initial hardware installation and
         for each additional phase as the OCEAN is scaled to full implementation. The
         Offeror must explain how system growth and expansion is to be accomplished and if
         additions would be disruptive to the ongoing system operation.


 5.1.3   Response time (from click to show)

         The system must provide a response time of:

         (a) 2 to 4 second response times for tasks that are simple

         (b) 3 to 6 second response times for common and frequent tasks that are complex

         (c) 4 to 8 second response times for infrequent tasks that are complex

         ODOD will define all of the above terms and tasks (points a-c) in the design phase.


 5.1.4   Load Capacity

         Under load conditions, the Offeror must configure network components to degrade
         gracefully rather than to fail catastrophically.

         Domain name services will be provided by ODOD and must be separate from the
         application, database and Web servers proposed for OCEAN.

         The Offeror must design the Internet applications to run on the platform that provides
         the best combination of cost, functional effectiveness, and compatibility with
         established standards, interoperability, supportability, flexibility, security and
         performance.

         The Offeror must design the Internet applications for “high availability” 7 x 24 access
         outside of scheduled maintenance, even if the system cannot immediately support it.

         The Offeror must perform a final load test to ensure proper performance at peak
         capacity to demonstrate the growth and reliability of the system, including the
         analysis, evaluation and verification of the performance of all system components
         and the full system, (which include telecommunications networks, hardware, and
         software).


5.2 Operations Requirements

 5.2.1   Operation by ODOD

         The system must be able to be operated and maintained by ODOD MIS staff without
         the intervention of the vendor or other third parties after the contract has expired.


                                           21 of 39
6 Security and Sustainability Requirements

 6.1 General

     The design of OCEAN must provide security for the data entered and a high level of
     confidence for the ODOD and Agency user. The Ohio Administrative Code section 123:3
     sets the standards for State of Ohio applications. The data processed and stored in
     OCEAN will contain sensitive information such as Social Security Numbers, dates of birth,
     addresses, and telephone numbers. This data must be protected within the OCEAN system
     and during all transmissions to authorized users of OCEAN (Agencies and other State
     Agencies).

     The contractor may make use of different technologies to provide security services, but the
     application’s security must follow the state architecture and:

           1. Application security should use existing infrastructure security services.
           2. If existing infrastructure security services cannot be used, application security
              should use open standards, or ubiquitous proprietary standards (e.g. RACF) to
              ensure interoperability.
           3. All Internet transactions that involve non-public or financial data must employ
              strong encryption and digital certificate authentication services.
               Note: For information on what constitutes non-public data please see Section
               149.43 of the Ohio Revised Code: http://orc.avv.com/title-1/sec-149.43.htm
           4. Employ secured connections (i.e., direct or a VPN (virtual private network)) for
              extranet data exchanges involving non-public or financial data.
           5. Direct all Internet traffic through a single hardened “choke point”, so that multiple
              connections do not compromise security and in order to facilitate monitoring of
              traffic to the network.




   6.1.1     Portal Access

             The OCEAN is to be a closed system accessible only by authorized ODOD and
             Agency staff. As such, the OCEAN system must provide security controls to prevent
             unauthorized access to the OCEAN Portal and only allow authorized computing
             systems and users.

             OCEAN must disallow anonymous users and report any attempt by an unauthorized
             user to gain access.

             OCEAN must restrict the number of Login failures and lock out the UserID after the
             number of failed attempts has been exceeded.

             OCEAN must provide the ability to terminate idle sessions requiring the User to Log
             into the system with a new Login.




                                               22 of 39
6.1.2   Communications Security

        Internet will be used to provide communications between Agency computers and the
        OCEAN. Data entered, displayed, and reported must be protected during
        transmission to and from the OCEAN. The minimum communications standard to be
        used is Secure Socket Layer, 128-bit encryption for all OCEAN data communications.

        Web forms will not employ the use of Cookies or other data storage techniques of the
        Browser to prevent storing sensitive applicant data on the computers accessing the
        OCEAN.

        Browsers accessing the OCEAN must utilize secure communications when sending
        and receiving data.

        OCEAN shall monitor idle time of each session. After XX minutes of idle time the
        OCEAN shall send a termination form to the users Browser and terminate the
        session requiring the user to Login.

        The design must require all fields be parsed to prevent known Hacker tricks, such as
        SQL injection.

        All URL arguments must be validated to insure valid values, lengths, etc.


6.1.3   Documentation

        The contractor must document the security functionality of OCEAN and provide the
        following:

               Security Features Users Guide – This guide must present summary and
                detail information that describes the security features provided by the
                system, guidelines on how to use these features, and how these features
                interact with one another.
               Security Design Documentation – This is a description of the developer’s
                philosophy for the protection of OCEAN data and must include an
                explanation of how this philosophy translates into the functionality and
                maintenance of the system. If distinct modules comprise the system’s
                security features, then this documentation must describe the interfaces
                between the modules.

6.1.4   Systems Architecture

        OCEAN must be built with a physical architecture so that ODOD and Agency staff,
        and other State of Ohio staff using a web browser, can access the system. ODOD
        staff members will access the functions of OCEAN over an organizational intranet,
        while Agency and all other users will access OCEAN via the Internet.


6.1.5   Designation of Roles & Access Rights

        Applicant data in the OCEAN system needs to also be protected so that only those
        individuals with a Need-to-Know shall have access. Therefore the OCEAN must


                                        23 of 39
provide the capability to assign and manage access to information for the ODOD and
Agency staff with assignable rights for:

       Viewing (Read Only)
       Creation
       Editing
       Deleting or Archiving
       Dissemination
OCEAN must allow ODOD and Agency management to create and change access
rights for each role by selecting functions that each individual may perform. ODOD
and Agency management must be able to assign a member of their staff the role of
manager, supervisor, or staff member. OCEAN must provide the capability to select
work functions for each role. This work function must be a series of on/off switches
that allow the person assigned that role to either perform a given function or not.

The following figure is a pictorial representation of this concept. This is not meant as
a design but rather as a means of communicating the requirement of providing a
tiered access allocation mechanism by role and function.




                                  24 of 39
John Doe 
                  Role
             Internal User
             Manager                 Functions                        Access Rights
             Supervisor                                New Applicant Account View Create Delete Modify
             Staff Member          Applicant     
                               New Employer Account
             External User     New TPA Account
                               HEAP                     Contact Information                  
             Employer
             Agency            PIPP
                               Successorship            Ownership
                                                        Location                             
             TPA               Determination
                               CSBG                     Wages
                                                        FEIN                                 
             Utility                                                                         
                .              Bonding
                               ROMA                     Type
                                                        TPA of heat
                                                        Message Box
                                                        Name                                 
                .                .                                                           
                                                        Account Status
                                 .                      Account Status
                .                                           .
                                 .                          .
                                                            .




     6.1.5.1        Data Access Levels

                    OCEAN must be able to tie user roles and responsibilities, as described above,
                    to access and modification privileges of data streams or data elements that are
                    stored within the system. For each user, the system must mediate what data is
                    visible and which programs or transactions can be used to manipulate the data.


     6.1.5.2        Administration Access

                    The system must use industry standard software that allows one or more
                    centralized network administrators to establish, manage, and maintain user and
                    data security by classification or area of focus.


     6.1.5.3        Storage

                    The system must not store any security or application data on the client system.
                    The intent is to prevent any opportunity for analyzing the client system for data
                    entered by an Agency or ODOD employee. This approach must extend to the
                    cookies and any caching of HTML pages.


   6.1.6     Application Security

             Each domain must have separate registration, authentication, and account
             administration procedures to accommodate for the different nature of the users and
             the information being transferred.

             When the OCS/OEE customer or staff member performs an action that is incorrect,
             for example the entry of an invalid password, the system must not allow the user
             access into an area of OCEAN that requires authorization. The OCEAN must instead
             inform the user how to resolve the issue; i.e., explain that correct password must be
             entered. Passwords must be self-service with support for forgotten passwords.


                                                 25 of 39
6.1.6.1   Registration

          OCEAN must require each user to have a valid user name, password, and
          assigned access rights. OCEAN must provide the capability for a user to
          establish a unique user name and password that is at least 8 alphanumeric
          characters. The user must also provide their full name, association, and contact
          information before OCEAN accepts the request for a user name and password.


6.1.6.2   Authentication

          The system must validate the entry of a user name and password combination
          and if correct, issue a token. This token is a server-side tag allowing OCEAN to
          track the user until the user logs out or the session times out.

          The login process must establish the access rights and associate all automatic
          and manual transaction processes initiated by that user with that user. The
          system must provide an advisory warning message on any login screen
          regarding the unauthorized use of the business information and the possible
          consequences of violating this requirement.

          Upon authorization of the login user name and password, the system must
          display, for that user name, the date and time either of the last successful login or
          the number of unsuccessful attempts to access OCEAN since the last successful
          system access.

          The system must not allow simultaneous logins with the same user name and
          password. Should a user try to login more than once, OCEAN will ask them if
          they wish to terminate the active session. If they answer yes, then OCEAN must
          terminate the active session and establish a new session instantly, otherwise
          they will not be allowed to log in.

          OCEAN must automatically log a user out of the system after XX minutes of idle
          time. Idle time for the web portion of OCEAN is the time between interactions
          between the web client and server. For example, when navigating between
          pages or clicking a submit button must reset the maximum idle time value. The
          maximum idle time value must be a variable so it can be modified.

          OCEAN must provide a notification one minute prior to a time out. Should the
          session time out, OCEAN must display a web page informing the user that they
          have been logged out and that they must login again to continue. OCEAN must
          save, for twelve hours, any data entered or modified on the web page the user
          was on prior to termination of the session for redisplay upon login.

          After 3 unsuccessful logins the system will:

                 Disable the user account
                 Record the event for audit
                 Inform the user of a contact who will unlock the account




                                       26 of 39
  6.1.6.3   Passwords

            Passwords must be a minimum of 8 characters in length, include both letters and
            numbers, and not be case sensitive. Password must comply with the standards
            established by ODOD. OCEAN must require ODOD and Agency staff to change
            their password on a periodic basis and restrict the use of passwords that can be
            easily guessed. Passwords must not be displayed in the application at any time.


  6.1.6.4   Procedure

            Users in each domain will authenticate onto the system using a different login
            screen. Independent of the domain, the standard login process must be followed:


  6.1.6.5   Logoff and Session Timeout Procedures

            The user will either logoff OCEAN or the session will be timed out by the server.
            The system must then ensure that all objects created for the user at the back-end
            are destroyed and that the system exits cleanly.


  6.1.6.6   Account Administration

            The system must provide tools for the Systems Administrators allowing them to
            manage user accounts. This will include such tasks as resetting a password; and
            activating, suspending, or deleting a user account. These functions must be
            limited to only the System Administrators or other well-defined privileged users,
            e.g. Application Administrators.

            The security functions performed by the System Administrator must be identified
            and documented.

            The security functions performed by the System Administrator should be
            separable from the non-security functions performed by the System
            Administrator.


6.1.7   Accountability

        The system must provide the capability to ensure that relevant information about
        actions performed by users, or processes acting on their behalf; can be linked to the
        user in question in sufficient detail so that the user can be held accountable.

        The system must maintain information sufficient for after-the-fact investigation of loss
        or impropriety and must provide individual user accountability for all security relevant
        events.

        The system must protect this information from unauthorized access or modification.

        To accomplish this:




                                         27 of 39
            1. OCEAN must generate a security audit trail containing information sufficient
               for after-the-fact investigation of loss or impropriety and for appropriate
               management response, including personnel actions and pursuit of legal
               remedies.
            2. OCEAN must provide end-to-end user accountability for all security relevant
               events including the user identification information associated with any
               system request or activity and must be maintained and passed on to any
               other connected systems so that the initiating user can be traceable for the
               lifetime of the request or activity.
            3. The audit trail must be protected from unauthorized access. Only the System
               Administrator must be authorized to modify or delete the audit trail.
            4. The audit control mechanisms must be protected from unauthorized access.
            5. OCEAN’s System Administrator must be able to dynamically control during
               normal system operation the types of events recorded. This control must
               include selective disabling or enabling of the recording of default audit events
               or other optional events.
            6. For each recorded event, the audit record must identify, at a minimum:
                       Date and time of the event
                       User identification and associated point of physical access, e.g.,
                        terminal, port, network address, or communication device
                       Type of event
                       Name of resources accessed
                       Success or failure of the event
            7. OCEAN must not allow the recording of the Administrator actions to be
               disabled and all modification to the set of auditable events must always be
               recorded.
            8. OCEAN must not record any actual or attempted passwords in the audit
               trails.
            9. OCEAN must provide the capability for any audit control data, e.g., audit
               event masks, to survive a system restart.
            10. OCEAN must provide the capability for automatic copying of audit trail files to
                an alternate storage medium after an ODOD-specifiable period of time.
            11. OCEAN must provide the capability for automatic deletion of audit trail files
                after an ODOD-specifiable period of time. The system-supplied default must
                be 120 days.
            12. OCEAN must provide the capability to invoke any procedure for site control
                should it not be able to record audit records.
            13. OCEAN must generate an alarm to the System Administrator if it can not
                record audit records.
            14. OCEAN must provide tools for the System Administrator to monitor the
                activities of specific terminals or network addresses in real time.

6.1.8   Auditing

        The system must provide a capability to determine if security violations have actually
        occurred, and if so, what information or other resources were compromised.




                                         28 of 39
      The system must provide post-collection audit analysis tools that can produce
      exception reports, summary reports, and detailed reports on specific data items,
      users, time, event type, or communications facilities.

      The system must provide the capability for authorized ODOD and Agency staff
      members to review the audit and transaction logs.


6.1.8.1   Application Level

          The application level log must record actions performed by or against an
          applicant’s account, such as entering wage information.

          The system must automatically delete the audit events in the logs, as part of the
          application data purge procedures, after a set period of time established by
          ODOD.


6.1.8.2   System Level

          The system level log must allow review of key security events, including:

                 Logon and off of users, including failed logins
                 Change or reset of passwords
                 Creation or deletion of users
                 Amendment of user rights
                 Suspension or activation of user accounts
                 Archiving procedures
          The System Administrator must provide the capability to independently and
          selectively review the actions of any one or more users, including privileged
          users, based on individual user identity.

          The system must provide the capability to report all modifications to any named
          or user-accessible system resources.

          The system must provide a real-time capability to monitor the occurrence or
          accumulation of security relevant events that may indicate an imminent security
          violation and immediately notify the System Administrator when events exceed
          established thresholds. If the occurrence or accumulation of these security
          relevant events continues, the system must take the least disruptive action to
          terminate the event involved.

          The events in this log must be maintained for a minimum of 1 year.


6.1.8.3   Database Level

          Changes to the critical database tables must be logged with date, operator,
          record identifier, and before image of data.




                                       29 of 39
            The events in this log must be maintained for a minimum of 1 year.


  6.1.8.4   Maintenance Log

            The maintenance log must record system maintenance activities, such as
            resetting the web server and be separate from OCEAN, in electronic or physical
            form. The events in this log must be maintained for a minimum of 1 year.


6.1.9   Object Reuse

        The system must ensure that resources can be reused while preserving security.
        Resources that are allocated to a user must not contain any information related with
        prior usage by the system or another system user.

        The system must ensure that non-privileged users are not able to reference the
        contents of a resource that has been:

               Returned to the system after usage
               Allocated to that user by the system.

6.1.10 Accuracy

        The system must protect against unauthorized or undesired modification of data. This
        includes protection against all modifications of the system itself and the data
        maintained by the system unless initiated by an authorized user.

               The system must provide mechanisms to separate and protect:
                    o   A given user's programs and data from another users' programs
                    o   System's programs and data from any user's programs.
               To insure the currently installed software is consistent with the delivered
                software, i.e., no unauthorized modifications have been made, there must be
                verification procedures, e.g., use of modification dates, permissions,
                checksums, etc., in place
               The system must restrict usage of:
                    o   Privileged instructions
                    o   Supervisory state
                    o   I/O instructions
               The system must control and audit usage of the system operator's console.
               The system must limit, to the extent possible that still permits the effective
                usage of the system, the execution of system-supplied utilities
               The ability to modify or replace system-supplied utilities must be limited to
                only the System Administrator.
               The system must provide the capability to restrict or control the modification
                or replacement of the operating system software including any firmware.
               The system must provide the capability to provide for any named or
                user-accessible system resource:
                    o   Date and time of the last modification



                                           30 of 39
                      o    User name of the user that made the last modification
                 All application programs and users must have access to:
                      o    Checksum capability
                      o    Data encryption facilities that allow data to be stored in an encrypted
                           format
                 The system must provide the capability to periodically validate the correct
                  operation of the system. These mechanisms or procedures must address, at
                  a minimum:
                      o    Monitoring of system resources
                      o    Correct operation of on-site hardware and firmware elements
                      o    Detection of error conditions that might propagate throughout the
                           system
                      o    Detection of communication errors above a customer-specifiable
                           threshold
                 The system must provide the capability for the System Administrator to
                  generate a status report detailing the values of all configurable security
                  parameters.

  6.1.11 Data Exchange

          The system must promote the secure transmission of data over communications
          channels. The system must provide the capability to:

                 Identify the originator of any information received across communications
                  channels.
                 Send data across communications channels in an encrypted format.
                 Communicate directly from the point-of-entry to the authenticating system for
                  all authentication data.
                 Encrypt authorization data sent over public or shared data networks.
                 Use error detection protocols when sending information across
                  communications channels.

6.2 Reliability

  6.2.1   Real-time Failover

          The contractor must design security facilities that:

                 Deny access when they fail (e.g. if a packet filtering router goes down it
                  should not let any packets in).
                 Incorporates automated error detection, reporting and recovery into Internet
                  solutions.
                 Incorporates Backup Domain Servers (BDS), in the event the Primary
                  Domain Server (PDS) fails. Each BDS must synchronize with the PDS
                  periodically throughout the day and be capable of individually handling the
                  total system traffic load of the PDS without degradation in service.
                 Provide the capability to switch from one processor to the other on a
                  scheduled or emergency basis without adversely affecting any operation.



                                            31 of 39
  6.2.2   Backup & Storage

          The contractor must provide a written disaster recovery procedure.

          Backup standards should include RAID Drive arrays, SCSI Device structures, and
          scheduled regular rotations.


  6.2.3   Data Integrity

          The architecture must provide integrated security services to enable the enterprise to
          conduct safe and secure business electronically. The State of Ohio must be able to
          conduct business electronically while maintaining information availability,
          confidentiality and integrity.

          OCEAN must use Secure Sockets Layer (SSL) for securely communicating via an
          encrypted link between a Web browser and Web server, as well as for FTP and
          telnet, as needed.

          OCEAN must provide and maintain a single, accurate, and consistent system date
          and time across the enterprise to support digital signature and audits.

          The contractor must design the system to support the assumption that OCEAN will
          be organized around integrated and sharable data resources.

          OCEAN’s web application must access data resources using ANSI-standard SQL
          whenever possible.

          Invocation of stored database procedures is generally preferred to dynamic SQL in
          Internet applications for both security and efficiency purposes.

          When requesting private data from customers (e.g. social security numbers) provide
          an “opt out,” or another way for them to provide the information.

          Avoid data replication over the Internet.


  6.2.4   Redundancy

          Backup Domain Servers must provide redundancy for the Primary Domain Server.
          RAID arrays must provide database backup and recovery of on-line transactions.
          Also, Backup & Storage procedures handle routine, periodic backups.


6.3 Intrusion Detection & Dispensation

    The system must provide industry standard audit tools to monitor, log and filter undesirable
    data, intrusion detection and dispensation, virus protection, and to provide network
    integrity.




                                           32 of 39
     The system must provide event logging to focus on unusual incidents and patterns of
     activity, and to examine critical system files at regular intervals to identify any tampering.


 6.4 System Diagnostics

     The Offeror must describe the diagnostic tools provided by the proposed system and
     describe:

             How the system routinely self-administers diagnostic programs
             How system problems are automatically logged and reported, and
             How the problems are monitored.
     The Offeror must elaborate on the System Diagnostics (methods to detect, diagnose,
     report, and monitor potential or actual troubles and component failures).

     ODOD standards require that a newly developed enterprise system must adhere to the
     following “best practices” for its operating environment.

             Build a TCP/IP based network, using Simple Network Management Protocol
              (SNMP) to collect statistics and other information on network devices.
             Use Remote Monitoring (RMON) products to provide packet collection, decoding
              and analysis to the MAC layer of the Operating Systems Interconnection (OSI)
              stack, applications monitoring, report generation and bandwidth allocation.
             Use the Desktop Management Interface (DMI) standard as a management platform
              that enables a common standardized mechanism for systems management of the
              desktop while permitting vendor differentiation.
     Note: The Information Resource Management Commission must approve any deviation
     from these standards.



7 Standards

 The system must adhere to the following standards.


 7.1 ODOD IT Platform Standards
             Fully adhere to the technology architecture in Section 2
             Work within the ODOD emerging Software Development Life Cycle and CMM level
              of operation
             Utilize the ODOD standard database – Microsoft SQL 2000
             Utilize the ODOD standard project management and desktop tools – Microsoft
              Office Suite including Microsoft Project 2002
             Utilize the State standard software development environment for requirements
              traceability
             Utilize the standard system version control software
             Provide development services utilizing state-of-the-art languages and tools
              including but not limited to Microsoft .NET Framework




                                              33 of 39
          It is not mandatory, but preferred that the successful Offeror be certified at the
           Software Engineering Institute (SEI) Capability Maturity Model (CMM) level 3

7.2 State of Ohio Technology Security Standards

   The system must adhere to the State’s security standards for the availability, integrity, and
   confidentiality of Ohio’s information. This includes the identification, authentication,
   authorization/access control, and audit security services utilizing component technologies
   best practices, guidelines, and standards as defined in
   http://www.state.oh.us/das/dcs/opp/pdfs_other/SEC-V1.pdf.




                                           34 of 39

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:4
posted:5/26/2012
language:English
pages:39