Feasibility study and alternatives analysis

Feasibility Study and Alternatives Analysis

The Feasibility Study is the preliminary study that determines whether a proposed systems project is technically, financially, and operationally viable. The Alternatives Analysis, usually included as part of the Feasibility Study, identifies viable alternatives for the system design and development. Between them, the documents provide:
• An analysisof the system objectives, functional requirements, and system design concepts;
• A determination of the feasibility of applying automated systems to effectively, efficiently, and economically improve program operations;
• An evaluation of alternative approaches for reasonably achieving the objectives and goals; and
• Identification of a proposed approach.
1.1 Overview The FeasibilityStudy is a critical document which defines the initial system concepts, objectives, requirements, and alternatives. The study also forms the framework for the system development project and establishes a baseline for further studies.
1.2 Describe the Status Quo Following a general overview of the project, the Feasibility Study should establish the "status quo" in the State's management of benefitprograms. 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 followingfactors 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.
1.3 Define the Problems 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 tooslow, 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.
1.4Convert Problems to System Objectives 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 thesystem 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, objectivesshould 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...