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

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

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)

Requirements Analysis

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

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’

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’

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’

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.

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

JAD Participants

• Observers– to provide technical details

JAD Participants

• Scribes– often replaced by technology: take notes for later

consensus

JAD Participants

• Session Leader– a new, professional role– qualifications are vaguely defined• good listener• organized

JAD Participants

• Executive Sponsor– to add credibility to the entire exercise

JAD Participants

• Users– as many as possible, cross-area representation

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