Systems Analysis and Design 11th Edition Chapter 2 PDF

Summary

This document is Chapter 2 from the 11th Edition of 'Systems Analysis and Design'. It covers the concept of a business case, strategic planning, and SWOT analysis in the context of IT projects. The chapter also explains the importance of a mission statement and how the Systems Development Life Cycle (SDLC) serves as a framework for systems development.

Full Transcript

Systems Analysis and Design 11th Edition Chapter 2 Analyzing the Business Case Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. Chapter Objec...

Systems Analysis and Design 11th Edition Chapter 2 Analyzing the Business Case Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. Chapter Objectives  Explain the concept of a business case and how a business case affects an IT project  Describe the strategic planning process and why it is important to the IT team  Explain the purpose of a mission statement  Conduct a SWOT analysis and describe the four factors involved  Explain how the SDLC serves as a framework for systems development Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 2 Chapter Objectives (Cont.)  List reasons for systems projects and factors that affect such projects  Describe systems requests and the role of the systems review committee  Define operational, technical, economic, and schedule feasibility  Explain the factors that affect project priorities  Describe the steps and the end product of a preliminary investigation Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 3 Introduction  Business case: Justification for a proposal ◦ Requires consideration of the organization’s:  Overall mission  Objectives  IT needs  Systems development process ◦ Systems request ◦ Preliminary investigation ◦ Findings are submitted to management Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 4 A Framework for IT Systems Development  Strategic Planning Overview ◦ Strategic planning: Process of identifying long- term organizational goals, strategies, and resources ◦ Starts with a mission statement  Must reflect the firm’s vision, purpose, and values  Critical success factor: High-priority objective  What Is SWOT Analysis? ◦ Strengths, weaknesses, opportunities, and threats ◦ Examines a firm’s technical, human, and financial resources Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 5 A Framework for IT Systems Development (Cont. 1) FIGURE 2-1 A SWOT analysis might produce results similar to those shown here. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 6 A Framework for IT Systems Development (Cont. 2) FIGURE 2-2 This SWOT analysis example focuses on a specific asset, such as a company patent. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 7 A Framework for IT Systems Development (Cont. 3)  Strategic Planning for IT Projects ◦ Careful planning can help assure that:  The project supports overall business strategy and operational needs  The project scope is well-defined and clearly stated  The project goals are realistic, and tied to specific statements, assumptions, constraints, factors, and other inputs ◦ Planning tools  Microsoft Word and Excel  CASE tools  Visible Analyst Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 8 A Framework for IT Systems Development (Cont. 4) FIGURE 2-3 The Visible Analyst CASE tool supports strategic planning and allows a user to enter many kinds of planning statements. Notice the four SWOT categories highlighted in the list. Screenshots used with permission from Visible Systems Corporation. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 9 A Framework for IT Systems Development (Cont. 5)  The Changing Role of the IT Department ◦ Management and IT are linked closely  Remarkable changes have occurred in both areas ◦ Today, systems development is much more team- oriented ◦ The IT department is responsible for screening and evaluating systems requests  Larger firms may use an evaluation team or systems review committee Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 10 What Is a Business Case?  A business case should: ◦ Be comprehensive and easy to understand ◦ Describe the project clearly, provide the justification to proceed, and estimate the project’s financial impact  Questions answered by a business case ◦ Why are we doing this project? ◦ How much will it cost and how long will it take? ◦ Are there any risks involved? ◦ How will we measure success? ◦ What alternatives exist? Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 11 Information Systems Projects FIGURE 2-4 Six main reasons for systems requests. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 12 Information Systems Projects (Cont.) FIGURE 2-6 Internal and external factors that affect IT projects. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 13 Evaluation of Systems Requirements  Systems requests are evaluated by a systems review committee or a computer resources committee  Systems Request Forms ◦ Streamline the request process ◦ Ensure consistency ◦ Easy to understand ◦ Include clear instructions ◦ Indicate the required supporting documents ◦ Submitted electronically Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 14 Evaluation of Systems Requirements (Cont. 1) FIGURE 2-10 Example of an online systems request form. Source: Florida Institute of Technology Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 15 Evaluation of Systems Requirements (Cont. 2)  Systems Review Committee ◦ A broader viewpoint enables a committee to establish priorities more effectively than an individual  One person’s bias is less likely to affect decisions ◦ Disadvantages  Action on requests must wait until the committee meets  Members might favor projects requested by their own departments  Internal political differences could delay important decisions Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 16 Overview of Feasibility  Feasibility studies can be simple or exhaustive  Effort required depends on the nature of the request  Initial fact-finding involves: ◦ Studying organizational charts ◦ Performing interviews ◦ Reviewing current documentation ◦ Observing operations ◦ Surveying users Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 17 Overview of Feasibility (Cont. 1) FIGURE 2-11 A feasibility study examines operational, technical, economic, and schedule factors. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 18 Overview of Feasibility (Cont. 2)  Operational Feasibility ◦ A proposed system will be used effectively after it has been developed ◦ Can be affected by organizational culture ◦ Cannot be accurately measured but requires careful study ◦ Questions that can help predict a system’s operational feasibility  Is the project supported by management and users?  Will the new system result in a workforce reduction?  Do legal or ethical issues need to be considered? Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 19 Overview of Feasibility (Cont. 3)  Economic Feasibility ◦ Projected benefits of a proposed system out- weigh total cost of ownership (TCO) ◦ Determination of TCO requires cost analysis of:  People, including IT staff and users  Hardware and equipment  Software  Formal and informal training  Licenses and fees  Consulting expenses  Facility costs Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 20 Overview of Feasibility (Cont. 4) ◦ Tangible costs are measured in dollars ◦ Intangible costs can significantly affect organizational performance ◦ Tangible benefits can result from a decrease in expenses or an increase in revenues ◦ Intangible benefits are important to the company despite the inability to measure them in dollars Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 21 Overview of Feasibility (Cont. 5)  Technical Feasibility ◦ Technical resources required to acquire and use the system ◦ Questions analysts should ask  Does the company have the necessary hardware, software, and network resources?  Does the company have the required technical expertise?  Does the proposed platform have sufficient capacity for future needs?  Will a prototype be required? Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 22 Overview of Feasibility (Cont. 6)  Schedule Feasibility ◦ A project can be implemented in an acceptable time frame ◦ Issues that can affect schedule feasibility  Interaction between time and costs  Can the company or the IT team control the factors that affect schedule feasibility?  Has management established a firm timetable for the project?  What conditions must be satisfied during the development of the system?  Will an accelerated schedule pose any risks? Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 23 Evaluating Feasibility  Identify and weed out systems requests that are not feasible ◦ Some feasible requests may not be necessary  Requests that are not currently feasible can be resubmitted as new hardware, software, or expertise becomes available Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 24 Setting Priorities  Factors that Affect Priority ◦ Will the proposed system reduce costs? ◦ Will the system increase revenue for the company? ◦ Will the systems project result in more information or produce better results? ◦ Will the system serve customers better? ◦ Will the system serve the organization better? ◦ Can the project be implemented in a reasonable time period? ◦ Are the necessary financial, human, and technical resources available? Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 25 Setting Priorities (Cont.)  Discretionary and Nondiscretionary Projects ◦ Discretionary projects: Projects where management has a choice in implementing them ◦ Nondiscretionary projects: Management has no choice in implementing a project  Most of these projects are predictable  Annual updates to payroll  Tax percentages  Quarterly changes Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 26 Preliminary Investigation Overview  Interaction with Managers and Users ◦ Meet with key managers, users, and IT staff to describe the project, explain responsibilities, answer questions, and invite comments ◦ Focus on improvements and enhancements, not problems Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 27 Preliminary Investigation Overview (Cont. 1) FIGURE 2-12 Model of a preliminary investigation. Notice the importance of fact- finding in each of the four areas. FIGURE 2-13 Six main steps in a typical preliminary investigation. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 28 Preliminary Investigation Overview (Cont. 2)  Planning the Preliminary Investigation ◦ Step 1- Understand the problem or opportunity  Develop a business profile that describes current business processes and functions  Understand how modifications will affect business operations and other information systems  Identify the departments, users, and business processes involved  Consider using a fishbone diagram Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 29 Preliminary Investigation Overview (Cont. 3) FIGURE 2-14 A fishbone diagram displays the causes of a problem. Typically, you must dig deeper to identify actual causes rather than just symptoms. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 30 Preliminary Investigation Overview (Cont. 4)  Planning the Preliminary Investigation (Cont.) ◦ Step 2 - Define the project scope and constraints  Define the specific boundaries, or extent, of the project  Define project scope by creating a list with sections called must do, should do, could do, and won’t do  Avoid project creep  Project creep: Process by which projects with very general scope definitions expand gradually, without specific authorization  Identify constraints  Constraint: A requirement or condition that the system must satisfy or an outcome that the system must achieve Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 31 Preliminary Investigation Overview (Cont. 5) FIGURE 2-15 Examples of various types of constraints. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 32 Preliminary Investigation Overview (Cont. 6)  Planning the Preliminary Investigation (Cont.) ◦ Step 3 - Perform fact-finding  Gather data about project usability, costs, benefits, and schedules  Analyze organization charts, conduct interviews, review documentation, observe operations, and conduct a user survey  Analyze the data  Pareto chart  XY chart (scatter diagram) Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 33 Preliminary Investigation Overview (Cont. 7) FIGURE 2-17 A Pareto chart displays the causes of a problem, in priority order, so an analyst can tackle the most important causes first. In this example, the part number issue would be the obvious starting point. FIGURE 2-18 An XY chart shows correlation between variables, which is very important in problem solving. Conversely, a lack of correlation suggests that the variables are independent, and that you should look elsewhere for the cause. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 34 Preliminary Investigation Overview (Cont. 8)  Planning the Preliminary Investigation (Cont.) ◦ Step 4 - Analyze project usability, cost, benefit, and schedule data  Factors to consider  What information must be obtained, and how will it be gathered and analyzed?  Who will conduct the interviews? How many people will be interviewed?  Will a survey be conducted? Who will be involved? How much time will it take to tabulate the results?  How much will it cost to analyze the information and prepare a report with findings and recommendations? Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 35 Preliminary Investigation Overview (Cont. 9)  Planning the Preliminary Investigation (Cont.) ◦ Step 5 - Evaluate feasibility  Operational feasibility  Technical feasibility  Economic feasibility  Schedule feasibility ◦ Step 6 - Present results and recommendations to management  Prepare a report that includes:  An evaluation of the systems request  An estimate of costs and benefits  A case for action Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 36 Preliminary Investigation Overview (Cont. 10)  Planning the Preliminary Investigation (Cont.)  Format of a report  Introduction  Systems request summary  Findings  Recommendations  Project roles  Time and costs estimates  Expected benefits  Appendix Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 37 Chapter Summary  Systems planning is the first phase of the systems development life cycle  A business case should: ◦ Describe the project clearly ◦ Provide the justification to proceed ◦ Estimate the project’s financial impact  Factors that affect systems projects ◦ User requests, top management directives, existing systems, the IT department, software and hardware vendors, technology, customers, competitors, the economy, and government Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 38 Chapter Summary (Cont.)  Analysts evaluate the systems request and determine whether the project is feasible from an operational, technical, economic, and schedule standpoint  Steps in the preliminary investigation ◦ Understand the problem or opportunity ◦ Define the project scope and constraints ◦ Perform fact-finding and analyze project usability, cost, benefit, and schedule data ◦ Evaluate feasibility and present results and recommendations to management Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 39

Use Quizgecko on...
Browser
Browser