system thinking and problem solving for IT solutions

lauren II

lm_1_systems_thinking.pptx

Home >Information Systems homework help >system thinking and problem solving for IT solutions

Lesson 1.2

The New World of Systems Analysis and Design

Lesson 1.1

Preface to Systems Thinking

Introduction to Systems Thinking

Today’s Reference

Lesson 1.3

Systems Concepts for Systems Thinking

Lesson 1.4

Fact Finding Before Modeling

Preface

Gerald Weinberg on systems analysis and design …

I used to worry because nobody knew how to do systems analysis, but now I worry because everybody knows…

… And I used to worry because there weren’t any good books on systems analysis or design, but now I worry that there are several ... and because the books are so good that people will imagine they can learn analysis and design from a book…

… I worry that you can’t learn certain things from a book, but I also worry because you can … As a matter of fact, if this book succeeds, you will know less of analysis and design than you knew before…

… In the past decades, the potential power of information [technology] over our lives has grown. Our understanding of analysis and design has also grown – but not as fast…

Weinberg, G. (1988), Rethinking Systems Analysis and Design. New York, NY: Dorset Housing Publishing, pp. ix-xi.

Continued ...

… This book is not an alternative to the growing movements toward more “structured” [e.g., “object-oriented” or “agile” approach] design and analysis … But as they succeed, we will see more clearly [because of this book] that there are other [forces] we’ve been ignoring. This book is, therefore, a supplement to the more structured processes of analysis and design …

… And of course I worry because [systems] thinking is something none of us likes to do every day, least of all analysts and designers. If we think about matters we’ve put it aside as settled, we may turn up worrisome aspects we overlooked …

In that case, [this book] might be the cure you need. Taken in conjunction with a dose of the more structured material [JLW: such as UML and SysML], it should relieve the torment of worry – and help you become a more complete analyst…

A system is bigger than just hardware and software.

When designing a system you have to look at the holistic picture.

Yes, the system includes hardware and software

And it can include ”things” that need to be managed or controlled

But it also frequently includes and manages data, and it produces information

And it includes people and groups of people

And it includes organizations that operate in specific markets

And those organizations have policies, processes, and procedures.

What is thinking at a systems level?

Lesson 1.2

The New World of Systems Analysis and Design

Lesson 1.1

Preface to Systems Thinking

Introduction to Systems Thinking

Today’s Reference

Lesson 1.3

Systems Concepts for Systems Thinking

Lesson 1.4

Fact Finding Before Modeling

Preface

The Three Ostriches: A Fable

What were the facts of the fable (NOT the conclusions)?

The characters

The storyline

The results (again, NOT the conclusions)

What was the moral of the story?

What was the lesson learned by systems analysts/engineers?

Weinberg, G. (1988) Rethinking Systems Analysis and Design. New York, NY, USA: Dorset House Publishing, pp. 23-24.

It’s not know-how that counts; it’s know when.

No single approach or tool or technique will suffice in a complex world; so stay open to new information, tools, and techniques, and don’t fall in love with the latest systems analysis and design fads.

About what “fads” was Weinberg speaking?

1970s Structured Systems Analysis and Design (Key Ostriches: Gane, Sarson, DeMarco, Yourdon, etc.) (data flow diagrams and structure charts)

1980s Information Engineering (Key Ostriches: Chen, Martin, Finkelstein, and others) (entity relationship diagrams and event diagrams)

Computer-Aided Software Engineering (CASE) (Key Ostriches: Martin, Bachman, Whitten)

1990s Object-Oriented Analysis and Design (Key Ostriches: Booch, Jacobson, Rumbaugh, the OMG) (the Unified Modeling Language or UML; and the Rational Unified Process or RUP)

2000s Agile Methods (Key Ostrich: Ambler and an army of his evangelists) (The revolt against prescriptive methods) (But is it all it is marketed as being?)

2010s Systems Engineering (Key ostriches: OMG and “engineers”) (the System Modeling Language or SysML) Business Engineering (Key ostriches: OMG, Silver, and others) (the Process Process Modeling Notation

What’s next?

What is the OMG?

“I ask you … What’s in your systems thinking toolbox?”

UML

ERDs

BPMN

SysML

DMN

others

“Systems analysis is a new wine in an old bottle …

As the job changes, the analyst’s burden grows. When we are not replacing an existing system, design no longer follows directly from analysis. Two separate jobs become inseparable, for analysis [often] yields insufficient information to design what will come to exist…

Today, there [are] new jobs [JLW: such as business analyst and system architect], but the old names also persist…

We need new thoughts on what the analyst does – observing, modeling, designing, thinking – and how the analyst becomes a better analyst – education, professional behavior, and personal development”

Weinberg’s thoughts on SA&D; Updated by Whitten

Weinberg, G. (1988) Rethinking Systems Analysis and Design. New York, NY, USA: Dorset House Publishing, p. 3

Mastering the Complexity of Systems (of Systems)

“We live in an age of unmastered complexity” (Weinberg ‘1988; Whitten 2016)

The problems we seek to solve are more difficult … and more interesting

Scale … “bigger and smaller”

The cost of “failure” is greater

We need to master complexity using general systems thinking

Learn from similar situations outside our present situation

Learn how people think (and fail to think)

Learn how to properly “analyze and synthesize” a system in terms of its component parts and the relationships between those parts … systems modeling

Weinberg, G. (1988) Rethinking Systems Analysis and Design. New York, NY, USA: Dorset House Publishing, p. 4

So the systems analyst is also a designer

We do analysis where analysis is the separation of a whole into its constituent parts for the purpose of examination and interpretation.

But we also do synthesis (also called design) where synthesis/design is the (re)arrangement of the parts (from analysis) to create a new or improved system.

We don’t always do analysis and design in that sequence

And we frequently do analysis and syntehsis at the same time

Weinberg, G. (1988) Rethinking Systems Analysis and Design. New York, NY, USA: Dorset House Publishing, p. 4-5

Problem Solving … What is a Problem

The classic definition of a problem is “a question or situation that presents uncertainty, perplexity, or difficulty”

In the business world, the term “problem” has a broader interpretation:

A true problem – something is (will be) wrong and needs to be fixed.

Closest to the classic definition

An opportunity to improve a situation or condition to the benefit of the business(es) or an industry

A directive, either internal or external, to change the current situation or condition in the business or industry

REF: Wetherbe, J. and Vitalari, N. (1994) Systems Analysis and Design: Best Practices (4th ed.). St. Paul, MN, USA: West Publishing.

Supply chain : the biggest problem in business industry.

Directive problems are about data

The Job of the Analyst, Engineer, Architect, Technologist

In all of the above ‘jobs’, the important dimensions ARE given by human beings involved in the system – we, as IT systems people, cannot claim ignorance. At best, we failed to observe or ask the right questions

In all of the above jobs, we must seek answers to interoperability between a system, its environment, and other systems. No system is an island unto itself.

If we want to understand anything, we must learn how NOT to try to understand everything, at least not all at the same time.

We should avoid trying to describe all details of a system solution in a mountain of paper, real or virtual.

Paraphrased from Weinberg, G. (1988) Rethinking Systems Analysis and Design. New York, NY, USA: Dorset House Publishing, pp. 11-12.

The keys to successful systems work

The general systems approach … specifically system concepts, natural language, and mathematics

Observer training … and other fact finding methods that seem to be ‘ignored or oversimplified’ in a lot of systems analysis books

Learning to work with models – system modeling

Classic models such as entity relationship diagrams, structured natural language and decision tables

Modern models such as the Unified Modeling Language (UML)

Up-and-coming models such as the System Modeling Language (SysML) and Business Process Modeling Notation (BPMN)

Architectural thinking … working with stakeholders, views, and reusable patterns to describe systems

Self development

Understanding that it’s about more than programming (structured, object-oriented, or agile)

Collect and observe facts

ALL SLIDES AFTER THIS ONE ARE A WORK IN PROCESS,

AND THUS< SUBJECT TO CHANGE

Lesson B

The New World of Systems Analysis and Design

Lesson A

Preface to Systems Analysis and Design Thinking

Introduction to Systems Thinking

Today’s Reference

Lesson C

Classic Systems Concepts for Systems Thinking

Lesson D

Fact Finding Before Modeling

REF: Wetherbe, J. and Vitalari, N. (1979, 1984, 1988, 1994) Systems analysis and design: Best practices (4th ed) St. Paul, MN, USA; West Publishing.

Jim Wetherbe

What is system?

What is components of system thinking ?

What is black box thinking ?

Discuss the fundamental concept of system thinking.

Draw a diagrams using tools to understand system thinking (what is in your tool kit)

Read about the two philosophers…

The Two Philosophers: A Fable

What were the facts of the fable (NOT the conclusions)?

The characters

The storyline

The results (again, NOT the conclusions)

What was the moral of the story?

What was the lesson learned by systems analysts/engineers?

Systems thinking will help you better understand the tools I plan to teach you, but at some point you have to modify that thinking to address the specifics of the system at hand.

Weinberg, G. (1988) Rethinking Systems Analysis and Design. New York, NY, USA: Dorset House Publishing, pp. 40-41.

Facts:

Two philosophers riding two horses

Scientist  we now know the sun and moon are not the same, even though they look alike

Philosopher but both have a luminous essence, so they must be the same

Scientist  but what if that essence is not the same

Philosopher  mincing words

Scientists  so because a table has 4 legs and horse has 4 legs, they are the same

Philosopher  exactly

GO TOLUNCH

Scientists dismounts horse and sits at table

Philosopher surrenders saddle but stay s on horse to eat

Scientist puts saddle on table

Knocks over milk and spooks the horse

Scientist’s horse runs away

Philosopher's horse bucks and throws him to ground

It’s true that horses have legs and tables have legs. But it is still better not to eat on horseback, or put saddles on the table.

General systems thinking is fine, but don’t ever forget about specific systems thinking.

To understand an event, or a sequence of events, means to fit it into a preconceived scheme of thought or perception. It may be a scheme shared by many, or it may be one’s own private scheme. At one extreme are the conceptual schemes of science, called theories; at the other, the delusions of psychotics.

Anatol Rapoport

To understand a system, or a system of systems, means to fit it into a preconceived scheme of observed system concepts and thinking. It may be a scheme shared by many systems, or it may be one’s own private scheme. At one extreme are the conceptual theories; at the other, the delusions of those who blindly follow ostriches.

Jeffrey Whitten

What is general systems thinking?

Weinberg’s thoughts on general systems thinking

General systems thinking is a scientific-disciplinary-inductive approach to analyzing or designing systems (of all types)

“The main trouble with analysis [and design] comes when results drawn from one [problem domain] are erroneously applied to another.

General systems people are often as parochial as any other students of the universe. Thus, there are good and bad systems analysts and systems designers.

The general systems approach exists without the existence of any full-time general systems theorists, save perhaps Gerald Weinberg 

Anyone who claims to be a general systems theorist cannot be one, for there is no such thing. In other words, no one makes a living by “doing” general systems.

But general systems thinking is what we ALL do, when we dare, and when we recast it in the discipline of specific types of systems work.

“Things” that Weinberg (and others) include in a system

Hardware

Software

People

Weinberg focused an training, but there is more to the PEOPLE aspects of systems than training prefers PEOPLE (e.g., usability, resistance, etc.)

Facilities

Raw data, refined information, and messages

Weinberg focused on test data … and I cannot refute his argument

Whitten notes that this includes data at rest (files and database, not all automated), data in motion, data quality, and data protection

Policies and procedures

Documentation in many forms, structured and unstructured

And anything else that contributes to the system’s purpose and results

Changes made since class presentation are in green

Abstract Definition – A system is an arrangement of interacting or interdependent things forming an integrated whole, or a set of elements and associations which interact and form an integrated whole that serves some purpose.

Disciplinary Definition – An information technology-base system is a set of hardware, software, data and information, people, facilities, policies and procedures, documentation, and anything other thing of importance; plus the associations between these things that interact and form an integrated whole that serves some purpose.

Refined definitions of a “system”

And systems analysis and design (a.k.a. systems engineering) applies systems thinking by exploring and optimizing an arrangement of hardware, software, data and information, people, policies and procedures, documentation, and associations which form an integrated system that solves one or more problems, or meets a need.

And so how do we use systems thinking in our discipline?

Great Debate: Systems Theory versus Systems Technique

Theory is the notion or ideas about the way things work or the ways things are.

Techniques are just different methods or approaches to per performing different tasks.

Most systems analysis and design courses emphasize techniques.

But techniques should be based on certain theories.

Which is most important?

Someone who knows technique without theory is a dangerous person.

They often use techniques that are outdated and no longer important.

Importance of knowing both theory and technique

Ignorance … not knowing how to do something

Knowledge … knowing how to do something

Counterknowledge … thinking one knows how to do something, but is wrong

REF: Wetherbe, J. and Vitalari, N. (1979, 1984, 1988, 1994) Systems analysis and design: Best practices (4th ed) St. Paul, MN, USA; West Publishing.

Essential skills for successful systems professionals?

Meaning systems analysts, designers, engineers, architects, etc.

Some level of understanding of the problem domain, or a willingness to learn it

GREAT people skills – WHY?

People are the source of your missing and detailed knowledge about the problem and solution space

People are a vital “thing” inside every system (as “users”) (REF: Our refined definition of an IT system – a few slides ago)

Conceptual skills = systems theory, systems thinking, the systems approach

Ref: Nicholas Vitalari studied a large group systems analysts, discovering that those who were rated highest by their organizations approached problem solving differently from those who approached systems thinking using sound systems theory and concepts … the poorer analysts couldn’t “see the forest for the trees”

Technical skills mostly interesting because it is NOT sufficient by itself

What systems theory and concepts are needed?

Instructor’s approach? Just enough systems theory. More about systems concepts.

Definition of a system? (as previously defined; focused on an “arrangement of things”)

All systems exist in an environment of other “things” (ultimately, all other things … the universe … but all things not relevant to our system of interest)

Some “things” are internal to our system of interest

Some “things” are external to the system, but still important because they interact with the system

Some “things” are irrelevant to our system, and are usually ignored

Analysts find it useful to model systems (meaning draw pictures that represent and communicate reality)

For now, we will use general systems models.

As we progress into techniques, we will learn specific system models that address specific aspects of our systems.

A General Systems Model

The environment – at least, that which is relevant to our system

Outputs

Inputs

OUR SYSTEM OF INTEREST

Other

Systems

Other

Systems

Other Things

Thing

THE BASIC MODEL OF THE SYSTEM IS I-P-O

Observations about systems

No system can continue to operate for prolonged periods of time without interacting with its environment. The eventually need to renew resources from the environment.

All systems are subject to decay … they eventually reach a condition called entropy after which they either get replaced, or simply cease to exist

For example … and noting obvious over-simplification

SOCIETY – THE PUBLIC INTEREST

Graduates with new characteristics

Students with certain characteristics

EDUCATIONAL SYSTEM

Knowledge-bases

Publishers

Other Things

Govern-ment

Faculty

Staff

Buildings

Other

Books

Equipment

Students

NOTICE THAT STUDENTS ARE BOTH EXTERNAL AND INTERNAL TO THE SYSTEM

Systems Need Controls

To ensure proper operation of a system, some form of control must be introduced

Heating/cooling system uses a thermostat to introduce control

Business systems introduce internal controls to prevent fraud and assurance

Security (sub)systems introduce controls to prevent intrusion

Information systems use reports to introduce control

Well designed systems include some form of feedback and control loop

Inputs

Our System

Thing

Outputs

Other Systems

Inputs

Other Things

Comparator

Activator

Sensor

Objectives or Norms

Subsystems

Every system is part of a larger suprasystem

CURRENT HOT TOPIC IS “SYSTEMS OF SYSTEMS”

Has led to a systems analysis and design evolution into systems engineering

Almost all systems contain subsystems

Sometimes the factoring of systems into subsystems is artificial

The factoring of a system into subsystems is called decomposition

Because factoring is artificial, choices can impact quality

Analysts sometime speak of re-factoring systems to improve quality

Factoring is recursive, until additional detail is no longer needed (sometimes, a subjective decision)

Subsystems (continued)

Factoring and decomposition are strategies that analysts frequently use to manage complexity

The strategy allows analysts to apply “black box” theory to temporarily hide complexity

How a REAL engineer thinks about decomposition and factoring:

All systems exist in an environment

All systems are part of a suprasystem

Most systems consist of subsystems

Most subsystems consist of assemblies and subassemblies

Assemblies and subassemblies ultimate consist of parts or components

System model view of factoring and black box thinking

OUR SYSTEM OF INTEREST

A SUBSYSTEM

Thing

Looking at all the details in the system of interest at the beginning can be to complex.

So we choose to initially look at the system as a black box.

We probably look at the black box’s interactions with its environment, but that is not depicted in this slide

Then we factor the black box into sub-systems and study their associations and interactions

Could have been any number of subsystems

And sub-subsystems, etc. (not depicted on this slide)

The trick is to find “logical” groupings.

Eventually we get to examining the things and associations inside the subsystems

Thing

More about the connections between things

For every thing, or sub-thing identified in a system, there COULD be a associations between them … depicted as line connectors

Associations can depict very different things

Structure … this thing consists of these things

Relationships ... this thing is associated with this other thing in some way

Flow … this thing happens before this thing

Data flow … data from this thing flow to this other thing (and maybe back again)

Behavior … this thing causes a change to this thing

Decoupling… this thing decouples this other thing to allow them to operate indepdenently

Queues

Files and databases

Other associations … to be described when we start studying specific modeling tools

This will make more more sense when we get into specific modeling tools

The systems approach is the way of thinking about managing the complexity of problems rooted in systems. It provides a framework for visualizing internal and external environmental factors as an integrated whole. It allows the recognition of the function of subsystems, as well as complex suprasystems within which organizations (and IT products) must operate. System concepts foster as way of thinking which, on the one hand, helps the manager (analyst) to recognize the nature of complex problems and thereby to operate within the perceived environment. It is important to recognize the integrated nature of specific systems, including the fact each system has both inputs and outputs and can be viewed as a self-contained unit. But it is also important to recognize that systems are part of larger systems ...

Kenneth Boulding Inventor of the systems approach 1950’s

The Systems Approach

= Systems Thinking

What’s behind systems thinking?

A system is more than the sum of its parts …

Parts = “things” (an their attributes and properties), and “associations between things”

Things can be people, hardware, software, facilities, policies, procedures, documents, messages, data and information, etc. – anything needed to accomplish its purpose and results

Systems …

… have a suprasystem

… are composed of subsystems

… which are composed of assemblies

… which are composed of parts

What is system modeling?

A system model is some representation of the reality of a system

Reality can be existing or future system

Reality can be a particular subset or viewpoint of a system, intended for specific stakeholders

Models can take various formats

Real or virtual

Working or non working

Diagram or non-diagram

Combinations of the above

Models connect “ideas” to “implementation”

Characteristics of GOOD system models

Communication … to the various stakeholders

Language … including model syntax and solution vocabulary

Argumentation … defends that the system fulfills requirements

Persuasion .. that the system can and should be built as designed

Order … allows the team to attack problem in a consistent and orderly manner

Structure … accurately shows the “things” and associations” that comprise the system

Comprehensiveness … that the sum of the models = the complete system

Consistency … that different models do not conflict or contradict one another

REF: Long, D. and Scott, Z. (2011) A primer for model-based systems engineering. Lexington, KY, USA: Vitech Corporation.

For what aspects of system thinking are models useful?

Problem analysis … figuring out what is wrong

Requirements analysis … communicating with customers about the need

Architecture … communicating with customers and builders about the technical solution

Verification and validation of requirements and design

Fundamental constructs of system modeling?

thing

Association

Things and associations will be drawn with specific shapes and connections.

As needed they will be named and annotated with icons, markers, end-points to communicated meaning to intended stakeholders.

And they will be supplemented with textual and/or tabular descriptions to provide needed details

E = MC2

Putting it all together … lesson conclusion

Systems Engineering

Systems Analysis

Systems Design

Problem

Analysis & Requirements

Systems Architecture &

Specifications

Systems Thinking

The Systems Approach

System Modeling

Thing

Lesson B

The New World of Systems Analysis and Design

Lesson A

Preface to Systems Analysis and Design Thinking

Introduction to Systems Thinking

Today’s Reference

Lesson C

Classic Systems Concepts for Systems Thinking

Lesson D

Fact Finding BEFORE System Modeling

Chapters 3-4

Normal walk-in hours are Wednesday 8:30-11:30 and 1:30-4:30

Tomorrow I have a meeting from 8:30-10:00 AM.

There may eventually be another 30 minute meeting squeezed in there.

Otherwise, normal walk-in hours apply.

About office hours tomorrow

System modeling of IT solutions is very beneficial to successful implementation, and long-term maintenance and evolution; however, system modeling is dependent of facts.

Accordingly, a systems professional’s success in systems modeling is based on their ability to discover the facts to be represented in the models. We call these FACT FINDING TECHNIQUES.

Fact Finding … the basic premise

Fact finding techniques for systems professionals

Sampling and observation

Questionnaires and interviews

Focus groups and group thinking methods

Brainwriting/brainstorming

Pareto analysis

Benchmarking

Prototyping

Data analysis

Weinberg focus was on techniques in gold font

REF: Weinberg, G. (1988) Rethinking Systems Analysis and Design. New York, NY, USA: Dorset House Publishing, Parts 3 and 4. REF: Whitten, J. and Bentley, L. (2007) Systems analysis and design methods (7th ed.) Burr Ridge, IL, USA: McGraw Hill 0 Irwin.

Sampling (not covered by Weinberg)

Always look for existing documentation

Business mission, vision, goals … if they exist

Existing business policies and procedures

Sample business data (today, often electronic)

Existing system models and documentation

Examples of business and system issues

Overarching advice – validate currency of any and all of the above

Sampling applies to data

Sampling of blank forms is highly discouraged. Why?

Study statistical methods for sampling

Sample size

Selection of sample instances … randomization versus stratification

Sterilization of sensitive data

Use 4 citations when building diagram

Never sample blank forms

Weinberg’s thoughts on observation

Of all the things we’d like to teach systems [professionals], the art of observation seems the most elusive.

[For example] students may not have learned to observe without being observed, but they’ve all learned the opposite trick of seeming to observe when not paying attention.

The first law of observation – The observer must realize that s/he is, in fact, interacting with the system, and thus changing the system – this can contaminate the results.

Then Weinberg introduces the “black box method” as a concept to validate observations

Do not expect the system to be “fair” to the observer

There may be a gold mine of information lying about, if you understand the language

Systems often intentionally conceal information from observers for the benefit of the observed

Weinberg’s thoughts on observation (continued)

The Natural History of White Bread

When observing a system, always remember:

THINGS ARE THE WAY THEY ARE BECAUSE THEY GOT THAT WAY

Also, always remember that your source of facts may be part of the history

Study for understanding, not criticism

There were, at the time, good and sufficient reasons for decisions that seem idiotic today

The original developer may now be the system professional’s manager (or the original users may have made the decisions that seem idiotic today)

Always search for what’s good in the old system

Try to preserve the good – not just do away with the bad

The Railroad Paradox … a True Story

What were the facts of the fable (NOT the conclusions)?

The characters?

The storyline?

The results ? (again, NOT the conclusions)

What was the moral of the story?

Beware of systems thinking as follows:

Service is not satisfactory

Because of #1, customers don’t use, or they underuse the current system

Also because of #1, the customers request better service

Because of #2, the systems analyst denies the request.

Weinberg, G. (1988) Rethinking Systems Analysis and Design. New York, NY, USA: Dorset House Publishing, pp. 40-41.

Conclusion = All fact finding techniques (such as observation) can mislead you.

Facts

Citizens of Suburbantown AND the Train Service

Morning and evening service only

Date night problem

Train DID pass thru ST at 2:30 but did not stop

Petition with 253 signatures

Response

Learning from the Railroad Paradox

Other examples of the RR Paradox

The case study of PCs in an an auxiliary building

The case of university IT budget allocations to customer departments

The case of the system request for a brokerage firm

The case for improvement of subroutine handling in a new CPU

Lessons learned for systems professionals

Always be aware of the RR paradox – be sure you understand the dangers of its unbreakable logic.

Never use questionnaires without a certain amount of open-ended discussion with a few of the customers to interpret the results

Use present levels of service a a guide – but never a standard for future performance

If possible, supply some kind of trial of the new service before deciding to discard it based on the current situation

The Dog That Read Fables: A Fable

What were the facts of the fable (NOT the conclusions)?

The characters

The storyline

The results (again, NOT the conclusions)

What was the moral of the story?

Not all illusions are illusions.

Don’t let your desires, biases, or presuppositions, influence your fact finding efforts, especially your desire not to appear stupid

Your ability to draw accurate system models will be based on unbiased fact finding

Weinberg, G. (1988) Rethinking Systems Analysis and Design. New York, NY, USA: Dorset House Publishing, pp. 60.

Oops! Could not find a picture of a poodle reading.

Aesop’s Fables

Facts:

Dog read AESOP’S FABLES at library

Dog was furious about the way AESOP presented dogs as not very smart

Dog would not sacrifice a bone to get at his reflection in the water

Ham bone in water

He passed up a great meal

Reminder: Fact finding techniques for systems professionals

Sampling and observation

Questionnaires and interviews

Focus groups and group thinking methods

Brainwriting/brainstorming

Pareto analysis

Benchmarking

Prototyping

Weinberg’s thoughts on interviewing

Which also apply to questionnaires

The “surefire” question

The three surefire dating questions

Getting the right answers requires asking the right questions

The technique of “participant observation”

Whitten calls it “living the system”

Can be accelerated through the use of “meta questions.”

Great wrap up question = WHAT DO YOU THINK I SHOULD BE ASKING YOU NOW?

FOOD PREFERENCE – Do you like spaghetti? NO

FAMILY – Do you have a brother? NO

QUESTION OF PHILOSOPHY – If you did have a brother, would he like spaghetti?

Weinberg’s thoughts on interviewing

Which also apply to questionnaires

Always use self validating questions

Instructor loved the “special characters” question

FRAME EVERY TECHNICAL [or BUSINESS] QUESTION SO THAT THE REPLY WILL BE SELF VALIDATING

REPLY = INFORMATION + VALIDATION + NOISE

Use precision words like “what”, “how”, “which”, where”

Avoid imprecise words such as “is” and “will”, “are” etc. – anything that could result in YES or NO answers – we need the noise because, buried in that noise, is the validation of the information.

Sometimes you need to specifically ask for the validation as follow-up questions

WHAT IS THE SOURCE OF THAT _______?

WHERE CAN I FIND DOCUMENTATION SUPPORTING THAT _______?

WHAT OTHER INFORMTION DO YOU HAVE THAT SUPPORTS _________?

FOOD PREFERENCE – Do you like spaghetti? NO

FAMILY – Do you have a brother? NO

QUESTION OF PHILOSOPHY – If you did have a brother, would he like spaghetti?

Weinberg’s thoughts on interviewing

Which also apply to questionnaires

The question is …?

Avoid compound questions … break them into multiple questions

Wait for the answers between each question … even when the respondent does not immediately answer

Don’t ask leading questions

Don’t ask loaded questions

Don’t ask questions that suggest the answer (somewhat leading)

Don’t include parting shots

Don’t ask controlling questions

FOOD PREFERENCE – Do you like spaghetti? NO

FAMILY – Do you have a brother? NO

QUESTION OF PHILOSOPHY – If you did have a brother, would he like spaghetti?

Whitten: Types of questions

Multiple choice, but only if accompanied by validation

Rating “questions”

Are not true questions

Start with an affirmative (positive) statement (as opposed to question)

Request Lichert rating of the statement

Strongly Agree

Agree

No opinion

Disagree

Strongly disagree

NOT APPLICABLE?

Ranking questions

Rating combined with ranking

The importance of LISTENING

HEARING ≠ LISTENING

A classic listening exercise

Best practices for improved listening

Minimize your own talking

Don’t be in a hurry

Watch YOUR interruptions … ignore THEIR interruptions

Not about being in control

Take notes

About the use of recordings

How important are proxemics and body language?

The Fairy and the Pig: A Fable

What were the facts of the fable (NOT the conclusions)?

The characters

The storyline

The results (again, NOT the conclusions)

What was the moral of the story?

If pigs had wings, they’d still be pigs

Interviewing and questioning is always limited by your customer’s knowledge, just as systems design is always limited by your customer’s values.

Weinberg, G. (1988) Rethinking Systems Analysis and Design. New York, NY, USA: Dorset House Publishing, pp. 60.

Facts:

Fairies get to go from heaven to Earth to grant wishes

Dog was furious about the way AESOP presented dogs as not very smart

Dog would not sacrifice a bone to get at his reflection in the water

Ham bone in water

He passed up a great meal

Anything else?

Sampling and observation

Questionnaires and interviews

Focus groups and group thinking methods

Brainwriting/brainstorming

Pareto analysis

Benchmarking

Prototyping

Weinberg focus was on techniques in gold font

Final thoughts on fact finding

Fact finding is an ART, not a science

By comparison, it’s much easier to teach you how to draw the system models and diagrams

It much more difficult to teach you to discover the facts to draw relevant and accurate system models and diagrams

But you must do BOTH to succeed

Weinberg and Whitten have now made you aware of the importance of fact finding … but YOU must execute!

During your career, invest time and effort to continuously improve your fact finding skills … your performance will benefit from the investment

Homework

Read Chapters 5-7.

Our next learning module will provide a process context for the above chapters

Topics

A systems problem solving approach

Different flavors of systems problem solving

Quality properties for system design