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

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

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

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

6. 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’

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

8. 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’

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

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

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

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

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 people and a facilitator.
JAD sessions can last a day, weeks or even months.

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

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

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

30. JAD Participants
Observers
to provide technical details 20

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

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

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

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

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

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