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

Systems Analysis and Information 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

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

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) 6

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

Requirements Analysis 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’

Requirements Business Requirements System 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’

Requirements Functional Nonfunctional 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’

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

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. Cow path – U of Colorado paving student walkways

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?

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.

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.

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”

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.

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

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

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

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/Apple Pay

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.

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

‘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

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

Interviewing: 5 steps Select interviewees Design questions 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”)

5 Steps in Interviewing Preparation Conducting the Interview Follow-up 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.

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.

5 Steps for JAD Selecting participants Designing session 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.

5 Steps for JAD Conducting the session Follow-up 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.

JAD Participants Analysts passive role except to manage unrealistic expectations Steps in a JAD Process: 1. locate executive sponsor 2. 8 to 12 participants identified 3. analysts initially learn the application under study 4. organize meeting usually in an off-site GDSS room 19

JAD Participants Observers to provide technical details 20

JAD Participants Scribes often replaced by technology: take notes for later consensus 21

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

JAD Participants Executive Sponsor to add credibility to the entire exercise 23

JAD Participants Users as many as possible, cross-area representation 24

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.

Questionnaires Administering Questionnaire Follow-up 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.

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

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

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