Describe when in the systems design phase should the feasibility analysis takes place and why or why not.

The life cycle of a system is an organizational process entailed in developing and maintaining systems. It assists in establishing a system project plan. This is because it provides, on the whole, a list of processes and sub-processes requisite for developing a system. The development of a system development life cycle implies an amalgamation of various activities. In other words, it can be said that a variety of activities put together are referred to as system development life cycle. In the terminology of system analysis and design, the development of a system also implies a software development life cycle.

Following are the different phases of the system development life cycle:

1. Preliminary study
2. Feasibility study
3. Detailed system study
4. System analysis
5. System design
6. Coding
7. Testing
8. Implementation
9. Maintenance

The different phase of system development life cycle is shown below.

The feasibility test is the second stage in systems designing. When the proposal for the system can be accepted by the management, feasibility analysis comes up as a logical extension. The feasibility study is essentially the test of the information system being proposed in understanding its acceptability in terms of its user workability, meeting the requirement of the users, effectively using the resources, and cost-effectiveness. These are classified as technical, operational, economic, and schedule feasibility. The key purpose of doing a feasibility analysis is to achieve the scope and not solving the problem. In the process of the feasibility study, the cost and benefits are estimated with greater accuracy to find the Return on Investment (ROI).

This helps in defining the resources required for completing the detailed investigation. As a result, we get the feasibility report presented to the management. This feasibility report may be accepted, or accepted with modifications, or rejected. This cycle moves ahead only when the management approves of the analysis.

The feasibility study is the introductory study that decides the viability of a proposed systems project technically, financially, and operationally. Second, the alternatives analysis, usually included as part of the Feasibility Study, identifies feasible alternatives for the system design and development. The design specifications are shown in the following manner:

1. An analysis of the system objectives, functional requirements, and system design concepts;
2. A determination of the feasibility of applying automated systems to effectively, efficiently, and economically improve program operations;
3. An evaluation of alternative approaches for reasonably achieving the objectives and goals; and
4. Identification of a proposed approach.

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 natural oils, the tension other policymakers. The environment of the student may be centralized or distributed. Regardless of attributes, the existing operating environment should be described. The feasibility analysis critically documents and 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.

On the basis of 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 present, the 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.

While defining objectives, various leadership elements demonstrate costs, time schedules, level of effort, effortlessness of future modification and expansion, allowable operational changes, and system security and reliability. Whatever the element requiring development, purposes be supposed to be defined in a clear, specific, and measurable mode and in terms general enough to be met using different automation strategies.
Important methods of resulting system objectives are critical to analysis if used to conduct support the Feasibility Study, requirements analysis, or development of testing plans. In terms of the Feasibility Study, the aims form the structure for the formulation of the initial system requirements, are utilized to determine the acceptable level of presented alternatives, and appearance the basis for generating costs and benefits during the ensuing Cost/Benefit Analysis.

Constraints lie outside the system and have a direct impact on the system design effort. There can be different constraints which are:

• Technological constraints which ensure the newly installed systems should be compatible with existing equipment;
• Socio-political constraint emphasizes that the acceptance of the model.
• There arose financial problems which stressed that the development and implementation costs must be within a specified budget.
• Operational constraints imply those which are, for example, space, staffing levels, skill mix, and capability and competence factors may limit system options.

On the other hand, system constraints should not be used to artificially confine 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 far as objectives are concerned, the system constraints are vital to the ensuing phases of the feasibility study. These objectives can influence system requirements and the acceptability of alternatives.

The underlying assumptions are related to factors that predict the application of the program or systems project. This can be exemplified through the system project operational, which implies the time required to plan, design, acquire, and implement the system plus its operational life, should be predicted, and therefore outlines a critical assumption during the feasibility analysis. The above-mentioned assumption directly affects the comparison time of costs and benefits of system alternatives and sets the range of time within which the system development breakeven point must occur.

There are four rules which apply to make certain assumptions which are:

• 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 the assumptions which will affect the analysis; and
• Document the logic underlying the assumption in the event its soundness needs to be reassessed.

Apart from systems life, other ordinary assumptions in cost/benefit analysis are project development and implementation schedule, which are estimated for future workloads, and projected costs and values.

Assumptions can be categorized as:

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