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...

BIS310: Week 4 BIS310: Structured Analysis and Design Feasibility Study and Business Requirements Statement -Selecting the Best Alternative Design Strategies - Interpersonal Skills and Communications BIS310: Week 4 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. BIS310: Week 4 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, schedule, and economic feasibility . BIS310: Week 4 Four Tests for Feasibility • Operational feasibility • Technical feasibility • Schedule feasibility • Economic feasibility (cost-benefit analysis) BIS310: Week 4 Operational Feasibility • Is the problem worth solving, or will the solution to the problem work? • How well would the candidate solution be received from management, system users, and organization perspective? (political) • Is the solution compliant with laws and regulations? (legal) BIS310: Week 4 Technical Feasibility • Is the proposed technology or solution practical? • Do we currently possess the necessary technology? • Do we possess the necessary technical expertise, and is the schedule reasonable? BIS310: Week 4 Schedule Feasibility • Given our technical expertise, are the project deadlines reasonable? BIS310: Week 4 Economic Feasibility • How Much Will the System Cost? • What Benefits Will the System Provide? – Tangible benefits – Intangible benefits • Is the Proposed System Cost-Effective? BIS310: Week 4 Cost-Benefit Analysis Techniques • • • • • Brake-Even Analysis Payback Period Analysis Cash-Flow Analysis Net Present Value (NPV) Return-on-Investment (ROI) Analysis BIS310: Week 4 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. BIS310: Week 4 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. BIS310: Week 4 BIS310: Week 4 BIS310: Week 4 Selecting the Best Alternative Design Strategy • 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 BIS310: Week 4 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. BIS310: Week 4 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. BIS310: Week 4 Interpersonal Skills and Communications • 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. BIS310: Week 4 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. BIS310: Week 4 Factual Format I. Introduction II. Methods and procedures III. Facts and details IV. Discussion and analysis of facts and details V. Recommendations VI. Conclusion I. II. III. IV. Administrative Format Introduction Conclusions and recommendations Summary and discussion of facts and details Methods and procedures V. Final conclusion VI. Appendices with facts and details BIS310: Week 4 – The abstract or executive summary is a one- or twopage summary of the entire report. – 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. BIS310: Week 4 Sample Outline for a 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 BIS310: Week 4 Formal Presentations – In order to communicate information to the many different people involved in a systems development project, a systems analyst is frequently required to make a formal presentation. • 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. BIS310: Week 4 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). BIS310: Week 4 Preparing for the Formal Presentation (cont.) – 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. BIS310: Week 4 Typical Outline and Time Allocation for an Oral Presentation 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) [...]... design strategies Candidate Systems Matrix • Select the one design strategy that is most likely to result in the desired information system – Feasibility Matrix BIS310: Week 4 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... documentation for reference and reporting BIS310: Week 4 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 BIS310:... briefly summarize the report, verifying the problem statement, findings, and recommendations BIS310: Week 4 Sample Outline for a 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 BIS310: Week 4 Formal Presentations... Introduction Conclusions and recommendations Summary and discussion of facts and details Methods and procedures V Final conclusion VI Appendices with facts and details BIS310: Week 4 – The abstract or executive summary is a one- or twopage summary of the entire report – The introduction should include four components: purpose of the report, statement of the problem, scope of the project, and a narrative explanation... 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 BIS310: Week 4 Factual Format I Introduction II Methods and procedures III Facts and details IV Discussion and analysis of facts and details V Recommendations VI Conclusion... Typical Outline and Time Allocation for an Oral Presentation 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... BIS310: Week 4 Interpersonal Skills and Communications • 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 BIS310: Week 4 Organizing the Written Report – Every report consists of both primary and secondary elements • Primary... 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) BIS310: Week 4 Preparing for the Formal Presentation (cont.) – Step 3: Prepare visual aids such as predrawn flip charts, overhead slides, Microsoft Powerpoint slides and the like — to... 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... many different people involved in a systems development project, a systems analyst is frequently required to make a formal presentation • 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 BIS310: Week ... technical, schedule, and economic feasibility BIS310: Week Four Tests for Feasibility • Operational feasibility • Technical feasibility • Schedule feasibility • Economic feasibility (cost-benefit... reference and reporting BIS310: Week Systems Analysis Reports • The Analysis phase results in a business requirements statement – This specification document is often large and complex and is rarely... 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