Following a general overview of the project, the Feasibility Study should establish the "status quo" in the State's management of benefit programs. The current environment may be a manual process, an automated process, or a combination of manual and automated functions. The environment may be paper intensive or dominated by electronic records. The environment may be centralized or distributed. Regardless of attributes, the current operating environment should be described.

Depending on the systems project being analyzed, the following factors may be addressed:

• Programmatic functions;
• Information architecture;
• System architecture;
• Hardware and software inventory;
• Interface and matching;
• Processing and data flow diagrams;
• Storage and retrieval;
• Inputs;
• Outputs;
• Workload,
• Validation / internal control;
• Security / Privacy;
• Emergency response, back-up, and disaster recovery;
• Personnel; and
• Space and Environment.

Once the current operating environment has been described, the problems with the current system (previously stated in the Planning APD) should be detailed. Problems may be functional - that is, the system may be incomplete, not fulfilling all the program requirements. Problems may be technical - for example, the system may be too slow, sized too small, or be obsolete and inefficient in terms of hardware or software. Problems may also relate to system cost or to access, limiting the ability of personnel to use system information to full potential.

This step should also include a determination of the seriousness of each problem and its effects on factors such as program clients and program financial considerations.

Once the current operational problems are identified, the State can develop specific system objectives. For example, the system may need to be redesigned to use the powerful attributes of database management software. Or the system may need to be redesigned to provide better service to clients or to support the distributed use and processing of information. Or the system may need to be re-engineered to simplify and streamline work processes for greater efficiency and economy.

In defining objectives, various elements must be considered: program needs, costs, level of effort, time schedules, allowable operational changes, ease of future modification and expansion, and system security and reliability. Whatever the element needing improvement, objectives should be defined in a clear, specific, and measurable manner and in terms general enough to be met using different automation strategies.

System objectives are critical to ensuing analysis - whether conducted to support the Feasibility Study, requirements analysis, or development of testing plans. In terms of the Feasibility Study, the objectives form the framework for the formulation of the initial system requirements, are used to ascertain the acceptability of alternatives, and form the basis for generating costs and benefits during the ensuing Cost/Benefit Analysis. See Table 2-1 on the following page for examples of system objectives.

Constraints are factors that lie outside - but have a direct impact on - the system design effort. Constraints may be:

• Laws and regulations - for example, State, Federal, or independent regulatory agencies may require specific design approaches for new systems or mandate specific changes to existing systems.
• Technological - for example, new equipment must be compatible with existing equipment;
• Socio-political - for example, the Governor mandates that all public assistance ADP functions be combined and managed by a common data base management system;
• Financial - for example, proposed development and implementation costs must remain within a specified budget.
• Operational - for example, space, staffing levels, skill mix, and capability and competence factors may limit system options.

However, system constraints should not be used to artificially restrict or direct the system. The objective is to plan the best system for the problem to be solved, not to fabricate and impose constraints that limit the system alternatives.

As with objectives, system constraints are critical to ensuing phases of the feasibility study. They can affect system requirements and the acceptability of alternatives.

Assumptions are factors predicted to apply to the program or systems project. For example, the project's operational or system life - the time required to plan, design, acquire, and implement the system plus its operational life - must be predicted and thus forms a critical assumption during the Feasibility Study. This assumption directly affects the period of time for comparison of costs and benefits of system alternatives and - for all practical purposes - sets the range of time within which the system development breakeven point must occur.

Four rules apply to making assumptions:

• Make assumptions when essential information cannot be determined or where the analysis is critically dependent on certain factors, conditions, or future events;
• State assumptions realistically and in precise terms;
• Include only assumptions which will affect the analysis; and
• Document the logic underlying the assumption in the event its soundness needs to be reassessed.

In addition to systems life, other common assumptions in cost/benefit analysis are project development and implementation schedule, estimated future workloads, and projected costs and values. Assumptions can be categorized as:

• Cost/Resource,
• Functional/Programmatic,
• Technical, and Systems Life.

• by area
• by how much

• by area
• in what manner

• in what manner
• by what measure

• by area
• by how much

• in what manner
• by what measure

• by area
• by how much

• by area
• in what manner

• by area
• by how much

• by area
• in what manner

• by area
• by how much

• by area
• by how much

• by area
• in what manner

• by area
• by what measure

• by area
• in what manner

• by area
• in what manner

• by area
• in what manner

• what records
• by how much

• what reports
• by how much

• by area
• by how much

• by area
• by how much

• in what manner
• by what measure

• by function
• in what manner

• by function
• in what manner

The Feasibility Study should include an initial statement of the functional and technical requirements for the system. The baseline requirements should relate to the objectives and constraints discussed in the previous sections, summarized as follows:

• Functional Objectives - the requirements should support mission and program needs. For example, the State may require that the new system improve service to the public and be compatible with and capable of accessing information in related State benefit systems.
• System Objectives - the requirements should be developed in a manner which will support the objectives. For example, if a system objective is to allow processing at the local level, the initial system requirements should reflect a distributed system and the need to analyze the new information architecture during the system design phase.
• System Constraints - The functional and technical requirements should conform to, rather than oppose, the system constraints. For example, if the Governor has mandated a single, integrated data base, systems built of separate data bases should not be considered.

An overview of the system requirements should reflect a broad range of factors, for example:

• Functional, programmatic requirements;
• Information needs;
• System needs;
• Interface and matching requirements;
• Processing and data flow needs;
• Storage and retrieval requirements;
• Inputs;
• Outputs;
• Workload, projected over time;
• Validation and internal control needs;
• Security / Privacy requirements;
• Emergency response, back-up, and disaster recovery;
• Accessibility requirements for the disabled; and/or
• Space and Environment.

The requirements should be stated briefly and in functional terms, to the extent possible. Their development during the Feasibility Study supports the selection of suitable alternatives. These functional and technical needs are greatly expanded later in the planning phase through the Requirements Analysis.

Once the initial system requirements are defined, the State should verify the technical, operational, and financial feasibility of the project.

Technical feasibility refers to the capability of current technology and methods of operation in meeting user requirements. Technical feasibility should include consideration of the state of the technology - for example, is the technology "leading edge" (with commensurate risk) or is the technology "mature" (with associated industry standards and lesser risk).

Operational feasibility refers to the ability of the enhanced system to fit the operational pattern and resources of the organization.

Financial feasibility refers to the ability of the State to fund (with Federal financial participation) the costs of developing and implementing the system.

Since limited resources - especially human and dollars - may affect feasibility, findings from the technical, operational, and financial feasibility analysis may require redefining or appending the system objectives and constraints.

The first step in identifying alternatives is to survey the possibilities and to consider the wide range of alternatives which may be available. The first part of the process is analytical and judgmental, resulting in eliminating alternatives which are not technically or operationally feasible. Therefore, alternatives are measured against considerations of project feasibility.

States should consider more than one technological design alternative when considering an automation project. For example, a system may be centralized, relying on mainframes for the bulk of processing. Or a system may be distributed, relying on personal computers and minicomputers for the bulk of entry and processing. Table 2-2 suggests representative alternatives for different types of requirements.

Regardless of technological approach, current systems can frequently be modified - or another State's system may fulfill the programmatic requirements of Federal benefit programs and serve as a transfer model.

States are required by regulation [45 CFR §95.605.1(vi)] to consider transferring systems developed in other States to meet the requirements. This helps expedite system development, minimize cost, and ensure project success.

Whenever possible, several alternatives reflecting different technological approaches - including the options of modifying current systems and transferring another State's system - should be analyzed. The alternatives may represent opposing strategies and should be described in sufficient detail to permit differentiation.

All alternatives should meet the established objectives within the system constraints, and depend on costs and benefits to determine the most favorable alternative.

For each alternative developed, the effects and risks of the proposed alternative on the current environment should be described:

• Program impacts - determine how the new system initiative will affect current program operations and new program requirements;
• Equipment impacts - determine how new equipment requirements will affect current systems and whether technological risks, such as obsolescence, maintainability, availability, expandability, reliability, flexibility, and compatibility, are inherent;
• Software impacts - describe what additions, conversions, or modifications are needed on existing applications and support software;
• Information impacts - determine how information will be affected, including accessibility, conversion, reformatting into databases, and storage media;
• Organizational impacts - describe organizational, schedule, accountability, personnel, and skill requirement risks and changes;
• Operational impacts - set forth the effects on operations, such as user and operating center procedures; user / operator and other relationships; source data processing; data entry procedures; information storage, retention, and retrieval requirements; privacy; output reporting, media, and schedules; system failure and recovery procedures; and security and back-up requirements;
• Developmental impacts - identify the effect of the development activity on current computing, staffing (including users), space, system security, and contractual support resources;
• Space and facility impacts - describe the effect on space, both in terms of square footage and necessary modifications to facilities; and
• Cost impacts - set forth financial risks and factors that may affect developmental or operational costs and influence the development, design, and operation of the proposed system.

• Client/server LAN and micros
• Distributed
• Mainframe
• Minicomputer
• Work station
• Microcomputer (stand-alone)

• From other State agencies
• Commercially

• Reallocating or increasing personnel
• Manual systems or work processes

• Using In-house Services
• Using Contract Services
• Using a Combination

• Generalized, such as DBMS
• Specialized, such as payroll

• Using In-house Resources
• Using Contract Services
• Using a Combination

• Using In-house Services
• Using Contract Services
• Using a Combination

• Manpower Based
• Project Based
• Full Service, Per Call, On Call

• Program impacts - determine how the new system initiative will affect current program operations and new program requirements;
• Equipment impacts - determine how new equipment requirements will affect current systems and whether technological risks, such as obsolescence, maintainability, availability, expandability, reliability, flexibility, and compatibility, are inherent;
• Software impacts - describe what additions, conversions, or modifications are needed on existing applications and support software;
• Information impacts - determine how information will be affected, including accessibility, conversion, reformatting into databases, and storage media;
• Organizational impacts - describe organizational, schedule, accountability, personnel, and skill requirement risks and changes;
• Operational impacts - set forth the effects on operations, such as user and operating center procedures; user / operator and other relationships; source data processing; data entry procedures; information storage, retention, and retrieval requirements; privacy; output reporting, media, and schedules; system failure and recovery procedures; and security and back-up requirements;
• Developmental impacts - identify the effect of the development activity on current computing, staffing (including users), space, system security, and contractual support resources;
• Space and facility impacts - describe the effect on space, both in terms of square footage and necessary modifications to facilities; and
• Cost impacts - set forth financial risks and factors that may affect developmental or operational costs and influence the development, design, and operation of the proposed system.

• Minimize personnel expenses over the system's operational life;
• Require minimal physical facility changes;
• Assure high levels of availability, reliability, maintainability, or expandability;
• Meet requirements for ease of use and ready access to information;
• Achieve desired distribution of processing to minimize point-of-entry delays;
• Achieve redundancy to guard against total system outages;
• Limit development time; or
• Retain a centralized information repository for reasons of security.

• Purpose and Scope
• Study Methodology
• Points of Contact
• References (such as prior APDs)

• Programmatic functions
• Information Architecture
• System(s) Architecture
• Hardware and Software Inventory
• Interface and matching
• Processing and data flow
• Storage and retrieval
• Inputs
• Outputs
• Workload
• Validation / internal control
• Security / Privacy
• Emergency response, back-up, and disaster recovery
• Personnel
• Space and Environment

• Functional
• Technical
• Access
• Cost

• Cost/Resource
• Functional/Programmatic
• Technical

• Laws and Regulations
• Technological
• Socio-Political
• Financial
• Operational

• Cost/Resource
• Functional/Programmatic
• Technical
• Systems Life

• Functional, programmatic requirements
• Information needs
• System needs
• Interface and matching requirements
• Processing and data flow needs
• Storage and retrieval requirements
• Inputs
• Outputs
• Workload, projected over time
• Validation / internal control needs
• Security / Privacy requirements
• Emergency response, back-up, and disaster recovery
• Accessibility for Disabled
• Space and Environment

• Overview
• Ranking Criteria, if used
• Description of each alternative, including:
• Program impacts
• Equipment impacts
• Software impacts
• Information impacts
• Organizational impacts
• Operational impacts
• Developmental impacts
• Space and facility impacts
• Cost impacts