From Planning to Analysis

1. From Planning to Analysis • Deliverables so far: • system request • feasibility study • project plan • Next up: • requirements definition (today) • use cases • process models • data models

2. Systems Analysis andInformation Gathering • Systems Analysis can be broken into three phases: • understanding current (as-is) system • identifying potential improvements • developing a concept for the new (to-be) system

3. Objectives of Systems Analysis • System Integration: Developing a System which can readily be modified, enhanced, and data can be accessed by any new program(s).

4. Requirements Analysis • Key Steps in this Process: 1: Get User’s Definition of the ‘Ideal’ System 2: Modify this Definition to Accommodate Constraints 3: Trade Off Marginal Factors Against Added Costs timing depends on methodology during the project after the project (Version 1 – Version 2)

5. Requirements Analysis • Issues: • 1: Targeting User’s Expectations • 2: Preconceptions of the System Builders • 3: Changing Environment Over Time

6. Requirements Analysis • Requirements • What the new system must do ‘Computerize the lease application status process’ • Characteristics the new system must have ‘Show department currently working on a lease application from any authorized workstation’

7. Requirements • Business Requirements • a business process ‘handle payroll’ • System Requirements • a technical conversion of the business process ‘access pay/time data for the current period, calculate net pay, automatically direct deposit to prespecified account, and update accounts’

8. Requirements • Functional • relates directly to a process the system has to perform or information it needs to contain ‘retain current price data and availability on all inventory items’ • Nonfunctional • behavioral properties of a system ‘any number of users can access current price data and product availability in real time on the web’

9. Approaches to Analysis • The 4th edition of the textbook outlined three approaches. Each approach varies in the level of “intensity” with which change is desired: • business process automation • business process improvement • business process reengineering • The three approaches differed rather dramatically

10. Business Process Automation • The least “intense” form of analysis. Also cavalierly referred to as “Paving the cow path” • leaves the manual system essentially unchanged but makes processes more efficient by automating them. • Focuses on detailing the “As-is” system. Most energy is placed on understanding current system as new system is based on it. • BPA does not impact the way things are done, but rather how fast they are accomplished.

11. Business Process Automation • Things to think about: • Think about whether there is a root cause to the problem. By focusing on the problem rather than the solution, you may get an indication that a more revolutionary design of the system is necessary. • Question: What do you get if you automate a bad manual system?

12. Business Process Improvement • A notch up on the analysis “intensity” level. • This approach takes an evolutionary view of the system. • No radical changes but constant search for improvements. • Changes are made to the way things are done, not just the computer system but the business system as well.

13. Business Process Improvement • Things to consider: • more effort required in identifying potential opportunities. • Requires an analysis strategy and more information about alternatives. • Activity based costing • Benchmarking • Add more time when considering this improvement. Sometimes difficult to find an “end” to the project.

14. Business Process Reengineering • BPR = High level of “intensity” • a radical and fundamental rethinking of the business processes currently used • looking for dramatic improvements • high risk • increased time • very often associated with “downsizing”

15. Business Process Reengineering • Things to think about • BPR is concerned with radical change, so we need radical techniques to use BPR. • Resistance to change is highest here, because the stakes are highest.

16. Requirements Analysis Strategies • Problem Analysis • least intrusive • ask users and managers what the problems are and how to solve them • incremental approach • Root-Cause Analysis • deeper approach • find problems, then rather than looking to solutions, try to determine why these problems exist • typically results in a more in-depth analysis

17. Requirements Analysis Strategies • Duration Analysis • look at each business process and determine how long each individual activity takes • if the total time is much longer than the sum of the process durations, the activity is badly fragmented • a solution approach involves process integration or parallelization • Activity-based costing • rather than the duration, consider the cost of performing each business process • look for potential reductions or ways to streamline

18. Requirements Analysis Strategies • Informal Benchmarking • look to others’ performance and try to mimick ‘best of breed’ outcomes • Outcome Analysis • define success, usually in terms of the customer’s perspective and measure the ability of your system to lead to that success

19. Requirements Analysis Strategies • Technology Analysis • a newer approach as technology becomes more pervasive • explore how newer technologies can affect new opportunities and solutions • i.e. BYOD, microbrowsers, NFC

20. System Analysis Milestone: Developing an Analysis Plan • Once you have decided on the general approach to analysis you can create an analysis plan • An analysis plan outlines the activities that will be performed to understand current system, create alternatives, and suggest a new system. • For an example, see the Tune Source case at end of chapter.

21. Gathering Information • Chapter 3 discusses a number of methods for gathering information. These include • interviews • Joint Application Design (JAD) • Questionnaires • Document Analysis

22. ‘Traditional’ Approaches • Interviews • time consuming • expensive • Observation • marginal value in isolation • Questionnaires • cheap, fast • low response rate • non-response bias issues • Document Analysis • important, but again not in isolation

23. Less Traditional • Joint Application Design (JAD) • Fast • Fuller participation • In conjunction with newer techniques: • prototyping • RAD

24. Interviewing: 5 steps • Select interviewees • talk to people at different levels and different perspectives. • Design questions • use more “open ended” questions to understand perceptions and usage problems • Use closed ended questions to get facts (“How many users log on to the network”)

25. 5 Steps in Interviewing • Preparation • Over half the work in interviewing is preparation. Do your homework and make your life easy. You need to set the agenda. • Conducting the Interview • requires a particular skill set • two-way communication • glean insights • manage expectations • Follow-up • Write-up your interview and then hand it to the interviewee to read. This cuts down of confusion and protects you in a fight.

26. Joint Application Design (JAD) • An information gathering technique that brings together developers, managers, users, and analysts to work together to develop requirements. • A structured technique with 10-20 people and a facilitator. • JAD sessions can last a day, weeks or even months.

27. 5 Steps for JAD • Selecting participants • should be from a number of levels , technical, and non-technical. • Designing session • How long will session last, what are he agenda items to cover • Preparing session • understand the objective of the JAD meeting (for example discussing the “As-is” or “To-be” model.

28. 5 Steps for JAD • Conducting the session • set agenda and ground rules • look for JAD facilitator with experience. Running a good JAD is difficult. • Follow-up • sometimes necessary to provide a written report of the JAD session.

29. JAD Participants • Analysts • passive role except to manage unrealistic expectations

30. JAD Participants • Observers • to provide technical details

31. JAD Participants • Scribes • often replaced by technology: take notes for later consensus

32. JAD Participants • Session Leader • a new, professional role • qualifications are vaguely defined • good listener • organized

33. JAD Participants • Executive Sponsor • to add credibility to the entire exercise

34. JAD Participants • Users • as many as possible, cross-area representation

35. Questionnaires • Best use when there are a large number of people who need to contribute. • Select participants • (use random sampling (very important) • Design questionnaire • try to be clear and unambiguous. Ask important questions early in questionnaire while you have their attention. • Try to group similar questions together • remain consistent with style of question.

36. Questionnaires • Administering Questionnaire • response rates are generally dismal (less than 20%) • give them a reason to fill it out • minimize time needed to finish and return it. • Follow-up • provide feedback on what you have learned. People like to know that they have contributed.

37. Document Analysis • A critical part of analysis phase. Documents tell us a large amount about the company and the business process • Very important to understand the flow of documents and how things are done. • Documents are also essential for database design as they provide the fields and record of interest. • Many Systems Analysis tools exist to support this form of analysis

38. Selecting the Appropriate Technique • Each technique for gathering information has strengths and weaknesses.

39. Documenting the requirements • Reports (e.g. after interviews, JAD sessions) • Requirements tables - for each specific requirement • Use cases - describe system functions from the perspective of users, with their terminology • Decision tables - to document an organization’s complex business policies and decision-making rules • DFD’s and ERD’s