Presentation is loading. Please wait.

Presentation is loading. Please wait.

The Activities of the Analysis Phase

Similar presentations


Presentation on theme: "The Activities of the Analysis Phase"— Presentation transcript:

1 The Activities of the Analysis Phase

2 Activities of the Analysis Phase and Their Key Questions
Systems Analysis and Design in a Changing World, 3rd Edition

3 Techniques for Information Gathering
Analysis phase done to understand business functions and develop system requirements Original structured approach Create model of existing system Derive requirements from existing system model Current approach Identify logical requirements for new system Balance the review of current business functions with new system requirements

4 Information Gathering and Model Building

5 Fact Finding Methods Review existing reports, forms, and procedure descriptions Interview and discussion processes with users Observe and document business processes Build prototypes Distribute and collect questionnaires Conduct joint application design (JAD) sessions Research vendor solutions

6 Review Existing Reports, Forms, and Procedure Descriptions
Source: External industry wide professional organizations and trade publications Source: Existing business documents and procedure descriptions within organization Identify business rules, discrepancies, and redundancies Be cautious of outdated material Obtain preliminary understanding of processes Use as guidelines / visual clues to guide interviews

7 Analyzing Procedures and Other Documents
Types of information to be discovered: What problems exist with the existing system Are there opportunities to meet new needs What’s the organizational direction? Who are the “key stakeholders What are the values of the organization Are there any special information processing circumstances What’s the history of the current system design Are there rules for processing data

8 Analyzing Procedures and Other Documents (cont.)
Four types of useful documents Written work procedures Describes how a job is performed Includes data and information used and created in the process of performing the job or task Business forms Explicitly indicate data flow in or out of a system Reports Enables the analyst to work backwards from the report to the data that generated it Descriptions of current information system

9 Written work procedure is a business document that formally describes work processes, provides useful information regarding system functionality and logic.

10 Observe and Document Business Processes
Varies from office walkthroughs to performing actual tasks Not necessary to observe all processes at same level of detail May make users nervous, so use common senseCan document workflows with UML activity diagrams

11 On-site Observations Objective: To get as close as possible.
Performed by the analyst for knowledge gain. Analyst should listen more than talk. Analyst should approach the things with genuine interest. Should not enter into arguments. Four alternative methods: 1. Natural or Contrived 2. Obtrusive or unobtrusive 3. Direct or indirect 4. Structured or unstructured

12 Conduct Interviews and Discussions with Users
Effective way to understand business functions and rules Time consuming and resource expensive May require multiple sessions to Meet all users Understand all processing requirements Can meet with individuals or groups of users List of detailed questions prepared

13 What is Interviewing? Dialogue with user or manager to obtain their requirements Two forms: Open-ended: conversational, questions with no specific answers in mind Closed-ended: structured, questions with limited range of possible answers

14 Guidelines for Effective Interviewing
Plan the interview. Prepare interviewee: appointment, priming questions. Prepare agenda, checklist, questions. Listen carefully and take notes (tape record if permitted). Review notes within 48 hours. Be neutral. Seek diverse views.

15 Interview Step 1: Determine the People to Interview
Informal structures Step 2: Establish Objectives for the Interview Determine the general areas to be discussed List the facts you want to gather

16 Interviews Step 3: Develop Interview Questions
Creating a standard list of interview questions helps to keep you on track and avoid unnecessary tangents Avoid leading questions Open-ended questions Closed-ended questions Range-of-response questions

17 Interviews Step 4: Prepare for the Interview
Careful preparation is essential because interview is an important meeting and not just a casual chat Limit the interview to no more than one hour Send a list of topics Ask the interviewee to have samples available

18 Interviews Step 5: Conduct the Interview
Develop a specific plan for the meeting Begin by introducing yourself, describing the project, and explaining interview objectives Use engaged listening Allow the person enough time to think about the question After interview, summarize the session and seek a confirmation

19 Interviews Step 6: Document the Interview
Note taking should be kept to a minimum After the interview, record the information quickly After the interview, send memo expressing appreciation, including the main points discussed so the interviewee has a written summary and can offer additions or corrections

20 Interviews Step 7: Evaluate the Interview Unsuccessful Interviews
In addition to recording the facts obtained in an interview, try to identify any possible biases Unsuccessful Interviews No matter how well you prepare for interviews, some are not successful

21 Issue with Individual Interviews
Advantages Easier to schedule than group interviews Disadvantages Contradictions and inconsistencies between interviewees Follow-up discussions are time consuming Only one at a time

22 Group Interviews Interview several key people together Advantages
More effective use of time Can hear agreements and disagreements at once Opportunity for synergies Disadvantages More difficult to schedule than individual interviews

23 Sample Checklist to Prepare for User Interviews

24 Questionnaire Steps Selecting participants Designing the questionnaire
Using samples of the population Designing the questionnaire Careful question selection Administering the questionnaire Working to get good response rate Questionnaire follow-up Send results to participants

25 Distribute and Collect Questionnaires
Limited and specific information from a large number of stakeholders. Preliminary insight into business Not well suited for gathering detailed information Closed-ended questions direct person answering question Open-ended questions encourage discussion and elaboration

26 Good Questionnaire Design
Begin with non-threatening and interesting questions Group items into logically coherent sections Do not put important items at the very end of the questionnaire Do not crowd a page with too many items Avoid abbreviations Avoid biased or suggestive items or terms Number questions to avoid confusion Pretest the questionnaire to identify confusing questions Provide anonymity to respondents

27 Types No response direction or specific response.
Open ended Questions: No response direction or specific response. Only questions with space provided for the answers. Closed Questions: Fill-in-blanks Dichotomous(Yes/No) type Ranking scales Multiple choice questions Multiple choice with rating

28 Advantages It is economical and requires less skill.
It can be administered to large numbers simultaneously. Standardized wording and order of the questions and standardized instruction for reporting responses. The respondents feel greater confidence in the anonymity of a questionnaire. Less pressure on subjects for immediate responses. Respondents have time to think the questions .

29 Build Prototypes Preliminary working model of a larger, more complex system component Discovery, design, evolving prototypes Prototype should be Operative Working model to provide “look and feel” Focused to accomplish single objective Quick Built and modified rapidly with CASE tools

30 Prototyping Quickly converts requirements to working version of system
Once the user sees requirements converted to system, he will ask for modifications or will generate additional requests Most useful when: User requests are not clear Few users are involved in the system Designs are complex and require concrete form History of communication problems between analysts and users Tools are readily available to build prototype

31 Basic steps for prototyping
Identify the user’s information and operating requirements. Develop a working prototype that focuses on only the most important functions, using a basic data base. Allow the user to use the prototype, discuss requested changes, and implement the most important changes. Repeat the next version of the prototype with further changes incorporated until the system fully meets user requirements.

32 Joint Application Design (JAD)
Intensive group-oriented requirements determination technique Team members meet in isolation for an extended period of time Highly focused Resource intensive Started by IBM in 1970s

33 Joint Application Design Facilities
Conducted in special room Limit interruptions May be off-site Resources Overhead projector, white board, flip charts, work material Electronic support (laptops) CASE tools Group support systems (GSS)

34 The JAD Session Tend to last 5 to 10 days over a three week period
Prepare questions as with interviews Formal agenda and groundrules Facilitator activities Keep session on track Help with technical terms and jargon Record group input Help resolve issues Post-session follow-up

35 Managing Problems in JAD Sessions
Reducing domination Encouraging non-contributors Side discussions Agenda merry-go-round Violent agreement Unresolved conflict True conflict Use humor

36 Joint Application Development
JAD Advantages and Disadvantages Advantages Allows key users to participate effectively When properly used, JAD can result in a more accurate statement of system requirements, a better understanding of common goals, and a stronger commitment to the success of the new system Disadvantages More expensive and can be cumbersome if the group is too large relative to the size of the project

37 Validating the Requirements
Two basic approaches to validating requirements Predictive development Requirements assumed stable and feasible Requirements specified and validated beforehand Adaptive development Requirements are assumed difficult to document Requirements subject to change System prototypes used in validation process

38 Validating the Requirements (continued)
Structured walkthrough Reviews findings Reviews models based on findings Objective: find errors and problems Purpose: ensure that model is correct Conducting structured walkthrough Preparation Execution Follow-up

39 Scheduling walkthroughs
Walkthroughs should be conducted frequently Focuses on a specific and small piece of work Increases the likelihood of uncovering errors Before author has too great an ego investment Scheduled only when the author is ready About 4 or 5 people Advanced preparation (no more than 2 hours) should be required of and performed by each reviewer.

40 Conducting Walkthroughs
Coordinator chairs the meeting Walkthrough structure Author's overview? Reviewers should be able to understand the product without assistance Author's overview may "brainwash" reviewers into making the same logical errors as did the author Author's detailed walkthrough Based on logical arguments of what the design or code will do at various stages Requested specific test cases Coordinator resolves disagreements when the team can not reach a consensus

41 Walkthroughs: Guidelines
Set an agenda and keep to it Limit debate and rebuttal Identify problem areas, but don't attempt to solve every problem Limit the number of participants Insist upon advance preparation Train reviewers Develop a checklist for each reviewable product

42 Types of Walkthroughs Specification walkthroughs Design walkthroughs
System specification Project planning Requirements analysis Design walkthroughs Preliminary design Design Code walkthroughs Test walkthroughs Test plan Test procedure Maintenance reviews

43 Specification Walkthroughs
Objective - Check the system specification for: Problems Inaccuracies Ambiguities Omissions Participants User Senior analyst Project analysts Objects DFDs, Data Dictionary, ERDs, ...

44 Design Walkthroughs Objective - Check the architecture of the design for: Flaws Weaknesses Errors Omissions Participants User Analyst Senior designer Project designers Objects Structure charts, detailed design documents, ...

45 Feasibility Analysis Feasibility – the measure of how beneficial or practical an information system will be to an organization. Feasibility analysis – the process by which feasibility is measured. Creeping Commitment – an approach to feasibility that proposes that feasibility should be measured throughout the life cycle. No additional notes.

46 Six Tests For Feasibility
Operational feasibility – a measure of how well a solution meets the system requirements. Cultural (or political) feasibility - a measure of how well a solution will be accepted in an organizational climate. Technical feasibility – a measure of the practicality of a technical solution and the availability of technical resources and expertise. Schedule feasibility – a measure of how reasonable the project timetable is. Economic feasibility - a measure of the cost-effectiveness of a project or solution. Legal feasibility - a measure of how well a solution can be implemented within existing legal/contractual obligations. Conversion Notes Cultural (or political) feasibility and legal feasibility are new to the seventh edition. Teaching Notes It is useful to take an example information system and explain how it might fail each test of feasibility. For example, a payroll system might fail legal feasibility for a multi-national corporation faced with national laws regarding the exportation of employee data. Emphasize that all candidates should be analyzed according to all of the above criteria. Students should understand that rarely will any one candidate solution be the most feasible candidate according to all criteria.

47 Operational Feasibility: The PIECES Framework
Performance -- Does current mode of operation provide adequate throughput and response time? Information -- Does current mode provide end users and managers with timely, pertinent, accurate and usefully formatted information? Economy -- Does current mode of operation provide cost-effective information services to the business? Could there be a reduction in costs and/or an increase in benefits? Control -- Does current mode of operation offer effective controls to protect against fraud and to guarantee accuracy and security of data and information? Efficiency -- Does current mode of operation make maximum use of available resources, including people, time, flow of forms,...? Services -- Does current mode of operation provide reliable service? Is it flexible and expandable?

48 Con.. How do end-users and managers feel about the problem (solution)?
It's not only important to evaluate whether a system can work but also evaluate whether a system will work. A workable solution might fail because of end-user or management resistance. Does management support the project? How do the end-users feel about their role in the new system? What end-users or managers may resist or not use the system? People tend to resist change. Can this problem be overcome? If so, how? How will the working environment of the end-users change? Can or will end-users and management adapt to the change?

49 Cultural (or political) feasibility
Does management support the system? How do end users feel about their role in the system? What end users may resist or not use the system? How can this be overcome? How will the working environment change? Can users and management adapt to the change? Conversion Notes This is a new slide in the seventh edition.

50 Technical feasibility
Is the proposed technology or solution practical? Do we currently possess the necessary technology? Do we possess the necessary technical expertise? Technical feasibility assesses whether the current technical resources are sufficient for the new system. If they are not available, can they be upgraded to provide the level of technology necessary for the new system. Conversion Notes This is a new slide in the seventh edition.

51 Project Risk Factors Project size Project structure Development group
Team size, organizational departments, project duration, programming effort Project structure New vs. renovated system, resulting organizational changes, management commitment, user perceptions Development group Familiarity with platform, software, development method, application area, development of similar systems User group Familiarity with IS development process, application area, use of similar systems

52 High technical familiarity mitigates risk due to project size and structure. Low familiarity increases risk.

53 Cultural (or political) feasibility
Does management support the system? How do end users feel about their role in the system? What end users may resist or not use the system? How can this be overcome? How will the working environment change? Can users and management adapt to the change? Conversion Notes This is a new slide in the seventh edition.

54 Legal feasibility Copyrights Union contracts
Legal requirements for financial reporting Antitrust laws National data and work laws Conversion Notes This is a new slide in the seventh edition.

55 Economic feasibility During Scope Definition During Problem Analysis
Do the problems or opportunities warrant the cost of a detailed study and analysis of the current system? During Problem Analysis After a detailed study of the current system Better estimates of development costs and benefits During Decision Analysis Requirements now defined Development costs can be better estimated Conversion Notes This is a new slide in the seventh edition.

56 Economic Feasibility Cost-benefit analysis: identify all the financial benefits and costs associated with a project Tangible vs. intangible benefits Tangible vs. intangible costs One-time vs. recurring costs

57 Tangible Benefits Benefits that can be measured in dollars and with certainty

58 Benefits that cannot easily be measured in dollars or with certainty

59 Types of Costs Tangible Costs: can be measured in dollars and with certainty Intangible Costs: cannot easily be measured in dollars or with certainty One-time Costs: often associated with project start-up and development or systems start-up Recurring: a cost associated with ongoing evolution and use of a system

60 Possible Project Costs
Procurement Consulting, equipment, site preparation, capital, management time Start-up Operating systems, communications installation, personnel hiring, organizational disruption Project-related Application software, software modification, personnel overhead, training, data analysis, documentation Operating System maintenance, rental, asset depreciation, operation and planning

61 One-time Costs

62 Recurring Costs

63 Three Popular Techniques to Assess Economic Feasibility
Payback Analysis Return On Investment Net Present Value Teaching Notes While the textbook covers only the above popular techniques, it is important to stress that there may be others that organizations choose to use in assessing the economic feasibility of an investment. Stress the importance of determining the investment decision-making process or techniques used by the organization. It should also be pointed out that sometimes the techniques vary according to the individuals involved.

64 Payback Analysis Payback analysis – a technique for determining if and when an investment will pay for itself. Payback period – the period of time that will lapse before accrued benefits overtake accrued and continuing costs. No additional notes.

65 Present Value Formula Present value – the current value of a dollar at any time in the future. PVn = 1/(1 + i)n Where n is the number of years and i is discount rate Discount rate – a percentage similar to interest rates that you earn on your savings. In most cases the discount rate for a business is the opportunity cost of being able to invest money in other projects or investments Teaching Notes While you may want your students to know this formula, be sure to emphasize that PV tables are available and spreadsheets generally include a PV function. Point out that the lifetime of an investment may be dictated by an organization and its investment decision makers. Point out that the interest rate is often dictated. Many companies choose to use the current prime rate.

66 Return-on-Investment Analysis (ROI)
Return-on-Investment (ROA) analysis – a technique that compares the lifetime profitability of alternative solutions. The ROI for a solution or project is a percentage rate that measures the relationship between the amount the business gets back from an investment and the amount invested. Lifetime ROI = (estimated lifetime benefits – estimated lifetime costs) / estimated lifetime costs Annual ROI = lifetime ROI / lifetime of the system No additional notes.


Download ppt "The Activities of the Analysis Phase"

Similar presentations


Ads by Google