Chapter 2

So What Is the Problem?

SAD/CHAPTER 22

Learning Objectives

Develop an understanding of the concepts of problem recognition and problem definition

Be able to identify and explain the differences between problems and symptoms

Learn to apply two common symptom organization tools: the Ishikawa diagram and the PIECES framework

SAD/CHAPTER 23

Learning Objectives

Understand the concept of bounded rationality and its effects on natural problem solving ability

Review and explain a system classification approach that can assist in understanding the elements and actions of IS

SAD/CHAPTER 24

Learning Objectives

Develop a thorough understanding of the process of functional decomposition and its importance to SAD activities

Learn the detailed phases of the SDLC and the typical activities and deliverables associated with each

SAD/CHAPTER 25

Problems versus Symptoms

Problem– A difference between things as desired and things

as perceived (Cause & Weinberg, 1990)– One person’s problem can be another person’s

opportunity

SAD/CHAPTER 26

Problems versus Symptoms

Symptom– An outward or physical manifestation of a problem

that becomes noticeable as some variance from the norm

– A symptom is evidence of a problem, not necessarily the problem itself

SAD/CHAPTER 27

Figure 2-1. One Man’s Problem – Another Man’s Opportunity

SAD/CHAPTER 28

Problem Recognition and Definition

You cannot solve the problem if you do not know what the real problem is.– Scientists

Observe a phenomenon Formulate a hypothesis Conduct an experiment

– Systems Analysts Recognize a variance Investigate Propose a solution

SAD/CHAPTER 29

Figure 2-2. Analysts and Scientists Use a Similar Approach

SAD/CHAPTER 210

Problem Recognition and Definition

Cause and Effect– One common method to define a problem is to

explore the cause and effect trail created by its symptoms.

– If one can discover a common source for the symptoms, then one can assume that he or she has determined the nature of the problem.

SAD/CHAPTER 211

Problem Recognition and Definition

PIECES Framework– Performance– Information– Economic– Control– Efficiency– Service

SAD/CHAPTER 212

PIECES Framework

The need to improve Performance– Improve throughput: the amount of work performed

over some period of time.– Improve response time: the average delay between

a transaction and a response to that transaction.– Throughput and response time should be evaluated

separately and collectively.

SAD/CHAPTER 213

PIECES Framework

The need to improve Information and data– Too little or too much information– Lack of needed or relevant information– Lack of relevant information– Information that is not in a useful form– Information that is not accurate or timely– Information that is difficult to produce

– Illegal information

SAD/CHAPTER 214

PIECES Framework

The need to reduce Economic or cost impacts– Costs are unknown– Cost are untraceable to source– Costs are excessive– New markets can be explored to generate profit– Marketing can be improved– Opportunities to increase orders exist

SAD/CHAPTER 215

PIECES Framework

The need to improve Control and security– Input data is not adequately edited– Crimes are committed against data– Fraud or embezzlement– Ethics are breached based on data or information– Redundantly stored data is inconsistent in different files– Privacy of data is being violated– Processing or decision making errors are occurring

– System is deviating from planned performance

SAD/CHAPTER 216

PIECES Framework

The need to improve Efficiency– People or machines waste time– Machines or processes waste materials and

supplies– Effort required for tasks is excessive– Materials required for tasks are excessive

SAD/CHAPTER 217

PIECES Framework

The need to improve Service– The system produces inaccurate results,

inconsistent, or unreliable results.– The system is not easy to learn or to use.– The system is too complex or awkward.

SAD/CHAPTER 218

PIECES Framework

The need to improve Service– The system is inflexible to situations and exceptions

or new requirements.– The system does not interface well to other

systems.– The system is not coordinated (“left hand does not

know what right hand is doing”).

SAD/CHAPTER 219

Problem Statement

Once defined, the root problem must be communicated to a wide variety of parties: the users, the managers, the development team, and technical people.

Problem statement is the common accepted method for such communication

Also referred to as a Statement of Scope and Objectives

SAD/CHAPTER 220

Bounded Rationality

Proposed by Herbert A. Simon

Cognitive limitations of human beings make it impractical to consider all possible alternatives to a practical problem

SAD/CHAPTER 221

Bounded Rationality

Systems analysts are not likely to gather all relevant information available regarding a particular problem.

It suggests the need for guidance and structure in the identification of a problem and the selection of a satisfactory alternative (e.g. SDLC).

SAD/CHAPTER 222

Figure 2-4. Theoretical Problem Space and Bounded Rationality

SAD/CHAPTER 223

The Concept of Systems

A system is a set of interrelated elements, with an identifiable boundary, that function together to achieve a common goal.

SAD/CHAPTER 224

The Concept of Systems

The concept of interrelatedness– The elements of a system are interdependent.– Those elements work together to achieve the goals

of objectives of the system.

SAD/CHAPTER 225

The Concept of Systems

The concept of a boundary– A system a definable within the context of all other

systems and that its limits can be established by virtue of it having a definable boundary.

SAD/CHAPTER 226

The Concept of Systems

The common goal– The goal or purpose of a system is its reason for

being .– If a system has no reason to exist because it has

outlived its usefulness or it no longer can provide the necessary functionality, then the purpose is no longer important and the system is no longer necessary.

SAD/CHAPTER 227

System Classification

Open Systems Closed systems Figure 2-5

SAD/CHAPTER 228

Figure 2-5. Comparison of Characteristics for Open and Closed Systems

SAD/CHAPTER 229

Figure 2-6. A Typical Terrarium – A Closed System

SAD/CHAPTER 230

Closed Systems

Also referred to as stable or mechanistic system

Highly structured and routine in operation

SAD/CHAPTER 231

Open System

Also referred to as adaptive or organic systems Less structured and routine in operation Adapt to changes in internal and external

conditions

SAD/CHAPTER 232

The Subsystem

The process of breaking a system into its component elements is called functional decomposition.

It allows us to study a single part of a system (subsystem).

SAD/CHAPTER 233

Figure 2-7. The Concept of Functional Decomposition

SAD/CHAPTER 234

SDLC

Preliminary investigation phase Analysis phase Logical design phase Physical design phase Implementation phase Maintenance phase

SAD/CHAPTER 235

Figure 2-8. The Systems Development Life Cycle

SAD/CHAPTER 236

Preliminary Investigation Phase

Purposes– Formulate the initial problem statement in a precise and

understandable manner– Investigate technical, economic, and operational feasibilities

Deliverable– Preliminary feasibility study (baseline project plan)

SAD/CHAPTER 237

Analysis Phase

Purposes– Logical modeling– Assemble formal requirements for the system

Deliverables– DFD and ERD– Formal requirement definition

SAD/CHAPTER 238

Logical Design Phase

Purposes– Redesigning the existing to reflect the proposed

solution– Incorporate new features for the system

Deliverables– Final performance specification– Detailed logical models

SAD/CHAPTER 239

Physical Design Phase

Purposes– Convert the logical models into a physical model

Deliverables– Physical specification– A formal feasibility analysis

SAD/CHAPTER 240

Implementation Phase

Purposes– End user training– System conversion

Deliverables– System documentation– Training program and schedule

SAD/CHAPTER 241

Maintenance Phase

Purposes– Error correction and system enhancement

Deliverables– Fully functioning system

SAD/CHAPTER 242

Figure 2-9. Distribution of Types of Maintenance Agreements

SAD/CHAPTER 243

Life Cycle Phase Key Activities Primary Deliverables

Preliminary Investigation

- problem definition - estimate project scope - estimate project feasibility - estimate resource

commitment - go/no decision

- preliminary feasibility report - general problem statement

Analysis

- create logical models of current system

- refine problem statement via detailed symptom analysis

- DFD of current system - ERD for current system - formal problem statement - formal requirements

definition Logical Design

- revise current system logical models to reflect proposed system changes

- validate logical model of

- DFD of proposed system - ERD for proposed system - final performance

specifications

Physical Design

- determine hardware - determine software

specifications - conduct feasibility analysis

- detailed hardware - detailed software

specifications - final feasibility report

Implementation

- acquire hardware and software

- determine location - install the new system - create test data and conduct

- final performance test metrics

- fully trained end user - fully installed system - fully converted data files

Maintenance

- conduct post-implementation review

- perform requested and necessary changes to new system

- fully functioning system

Table 2-2. Activities and Deliverables During SDLC

SAD/CHAPTER 244

Systems Development Principles

Get the Users Involved Systems Analysis is Problem Solving ISs Are Capital Assets Good Ideas Can Become Bad Ideas Document Now Use the Divide-Conquer Approach

SAD/CHAPTER 245

Summary

The fundamental activity of the modern systems analyst is that of problem identification and solution development.

The concept of bounded rationality can help the analyst in identifying a problem and proposing a solution.

Systems development principles should be followed by systems analysts.

Chapter 2

End of Chapter