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