FEASIBILITY STUDY AND BUSINESS REQUIREMENTS STATEMENT

FEASIBILITY STUDY AND BUSINESS REQUIREMENTS STATEMENT tài liệu, giáo án, bài giảng , luận văn, luận án, đồ án, bài tập l...

Analysis and Design

Feasibility Study and

-Selecting the Best Alternative Design Strategies

- Interpersonal Skills and Communications

Feasibility analysis

• Feasibility is the measure of how beneficial

or practical the development of an

information system will be to an

organization

• Feasibility analysis is the process by which

feasibility is measured.

Analysis Phase Checkpoint

• Alternative solutions are defined in terms of their IS building blocks (hardware,

software, data, network, etc.).

• After defining these options, each option is analyzed for operational, technical,

Four Tests for Feasibility

• Is the solution compliant with laws and

regulations? (legal)

Schedule Feasibility

• Given our technical expertise, are the project deadlines reasonable?

Economic Feasibility

• How Much Will the System Cost?

• What Benefits Will the System Provide?

– Tangible benefits

– Intangible benefits

• Is the Proposed System Cost-Effective?

Cost-Benefit Analysis Techniques

• Brake-Even Analysis

• Payback Period Analysis

• Cash-Flow Analysis

• Net Present Value (NPV)

• Return-on-Investment (ROI) Analysis

Financial Analysis Tools

Guidelines to select the method for

comparing alternatives:

– Use Break-Even Analysis if the project needs

to be justified in terms of cost, not benefits

– Use Payback Period Analysis when the

improved tangible benefits form a convincing argument for the proposed system

Financial Analysis Tools (cont.)

Guidelines to select the method for

comparing alternatives (continued)

– Use Cash-Flow Analysis when the project is

expensive, relative to the size of the company

– Use Net Present Value (or ROI) when the

payback period is long or when the cost of borrowing money is high

• Generate a comprehensive set of alternative design

strategies Candidate Systems Matrix

• Select the one design strategy that is most likely to result

in the desired information system – Feasibility Matrix

Business Requirements Statement

 A consolidation of all system models, discovery prototypes, and supporting documentation is

sometimes called a requirements statement.

 All elements of the requirements statement are stored in the repository, but most systems analysts find it useful

to keep a printed copy of that documentation for reference and reporting.

Systems Analysis Reports

• The Analysis phase results in a business requirements statement

– This specification document is often large and complex and is rarely written up as a single report to system users and owners

– It is best reviewed in walkthroughs (in small pieces) with users and maintained as a

reference for analysts and programmers

• Written Reports

– The business and technical report is the

primary method used by analysts to communicate information about a systems development project

• The purpose of the report is to either inform or persuade, possibly both.

Organizing the Written Report

– Every report consists of both primary and

secondary elements

• Primary elements present the actual information

that the report is intended to convey Examples include the introduction and the conclusion.

• Secondary elements package the report so the

reader can easily identify the report and its primary elements Secondary elements also add a

professional polish to the report.

Factual Format Administrative Format

IV Methods and procedures

V Recommendations V Final conclusion

VI Conclusion VI Appendices with facts and details

– The introduction should include four components: purpose

of the report, statement of the problem, scope of the project, and a narrative explanation of the contents of the report

– The methods and procedures section should briefly

explain how the information contained in the report was developed — for example, how the study was performed or how the new system will be designed.

– The bulk of the report will be in the facts section

» This section should be named to describe the type of factual data to be presented (e.g., “Existing Systems Description,” “Analysis of Alternative Solutions,” or

“Design Specifications”)

– The conclusion should briefly summarize the report,

verifying the problem statement, findings, and recommendations.

Requirements Statement

• Executive Summary

• Introduction (What’s going on now)

• Background (How are we doing?)

• Business requirements (What’s needed?)

• Feasibility Study (Can we do it?)

• Proposed design phase plan and schedule

• Appendix

• Formal presentations are special meetings used to sell

new ideas and gain approval for new systems They may also be used for any of the purposes in the margin

In many cases, a formal presentation may set up or supplement a more detailed written report.

Preparing for the Formal Presentation

– Step 1: Define your expectations of the

presentation — for instance, that you are seeking approval to continue the project, that you are trying to confirm facts, and so forth

• A presentation is a summary of your ideas and proposals that is directed toward your expectations.

– Step 2: Organize your presentation around the allotted time (usually 30 to 60 minutes)

– Step 3: Prepare visual aids such as predrawn

flip charts, overhead slides, Microsoft Powerpoint slides and the like — to support your position

– Step 4: Practice the presentation in front of the most critical audience you can assemble

I Introduction (1/6)

1 Background

2 Problem Statement

3 Work completed to date

II Body of Presentation (2/3)

1 Summary of existing systems and cause-effect analysis

2 Summary description of proposed systems

3 Feasibility study (analysis of alternatives)

4 Proposed schedule to complete project

III Conclusion (1/6)

1 Questions and concerns from the audience

2 Call to action (request for authority whatever you require to continue the systems development

project)