Deductive, inductive, and abductive reasoning and their application in transforming user needs into a solution system

12/1/2016
Webinar Sponsored by Computer Aid, Inc.
Slide: 1
Applying Deductive, Inductive, and Abductive
Reasoning to the System Development Life-Cycle
(SDLC)

12/1/2016
Slide: 2
Didier Koffi
Principal Business Architect
Pragmatic Cohesion Consulting, LLC
didier@pragmaticohesion.com
Hosted by:
Jessica Dahbour
ITMPI
Jessica_Dahbour@compaid.com

12/1/2016
Slide: 3
About Presenter’s Firm
• Since 2010, Pragmatic Cohesion has provided state of the art
Business Architecture and Business Systems Analysis services that
take advantage of our cutting edge approach to Enterprise
Stakeholders’ collaboration and Business Model Assessment.
• Our latest product is named the EBMM-TRIADs™ 3-day
Assessment Workshop that measures your organization's ability to
deliver outcomes that properly respond to the expectations and
constraints imposed upon your business by its environment:
markets, customers, suppliers, partners, competitors, regulators,
shareholders, and various stakeholders. The assessment does so
by asking a comprehensive set of simple questions that only require
your familiarity with the various aspects of your business; NO books
of records or balance sheets needed!

12/1/2016
Slide: 4
CAI Achieves IT Operational Excellence
www.compaid.com

12/1/2016
Slide: 5
PDU Credits Available for this Webinar
• The PMI has approved this webinar with PDUs
• You will be eligible to receive 1.0 PDU credits
• Your PDU email will be sent to you
• This webinar is mapped to the TALENT TRIANGLE

12/1/2016
Slide: 6
Online Webinar Recordings
NOW AVAILABLE
• Anytime Access
• Hundreds of Topics
Visit:
www.ITMPI.org/library

12/1/2016
Slide: 7
Enjoy the benefits of ITMPI Membership
JOIN TODAY!
• UNLIMITED Free Webinar Recordings
• UNLIMITED Free PDU Credits
• Hundreds of Topics
Visit:
www.ITMPI.org/subscribe

12/1/2016
Slide: 8
Outline:
• Deductive Reasoning
• Inductive Reasoning
• Abductive Reasoning
• From Evidence to
Hypothesis
• From Solution System
Feature to User Need
• Requirements Validation
• System Verification
• Reasoning types across the
System Development Life
Cycle (SDLC)
• Illustrative Example
Applying Deductive, Inductive, and Abductive Reasoning to the System
Development Life-Cycle (SDLC)

12/1/2016
Slide: 9
Deductive reasoning is a form of reasoning that
shows that certain conclusions follow
necessarily from true premises
Thale’s Theorem:
Wikipedia
In geometry, Thales'
theorem states that if A, B
and C are points on a circle
where the line AB is a
diameter of the circle,
then the angle ∠ACB is a
right angle

12/1/2016
Slide: 10
Deductive reasoning is Top-Down, from generalizations
to particulars or from hypothesis to evidence.

12/1/2016
Slide: 11
Inductive reasoning asserts that something is
probably true given some evidence relevant to it.

12/1/2016
Slide: 12
• With Inductive reasoning we consider a “mass of
evidence” that we believe is relevant to a set of
hypothesis H. The probabilistic nature of inductive
inference comes from the following characteristics of the
“mass of evidence”:
– It is incomplete
– It is inconclusive (It is consistent to some degree with the truth of
every hypothesis in H)
– It may be vague or imprecise
– It may be dissonant (some of it favors one hypothesis and some
favor others)
– Its sources may not be perfectly credible

12/1/2016
Slide: 13
Abductive reasoning is concern with imaginative reasoning, a
process through which new ideas or hypotheses come into existence
based on observations.
In deductive reasoning a
conclusion is already
embedded in its premises.
In inductive reasoning, a
hypothesis or idea already
exists and we are just
establishing probabilistic
grounds for it.

12/1/2016
Slide: 14
Abductive reasoning is also used to generate inference
networks: the skillful combination of relevance and credibility
characteristics of evidence.

12/1/2016
Slide: 15
Eco’s “Overcoded Abduction” according to Schum
• We observe clue E* (E* being evidence that
event E occurred)
• Based on our prior knowledge of contexts in
which things like event E have occurred, we
say: “Whenever something like H has
occurred, then something like E has also
occurred.” Rephrased, we might say: “If H
were true, then E would follow as a matter of
course.”
• Thus, there is reason to suspect that H may
explain the occurrence of clue E*. In other
words, clue E* points to H as a possible
explanation for its occurrence.
From Evidence to Hypothesis

12/1/2016
Slide: 16
From Evidence to Hypothesis Example
H=Hypothesis Set H=It rained overnight; Hc= It did not rain overnight
E=Event relevant in an Inference about H E=My lawn is wet; Ec=My lawn is not wet
E*=Evidence that E occurred E*:My hands were wet after touching a patch of grass
From E* to E : Credibility Stage
P(E*|E) Hit probability P(My hands were wet after touching a patch of
grass | My lawn is wet)
P(E*|Ec) False positive probability P(My hands were wet after touching a patch of
grass | My lawn is not wet)
From E to H : Relevance Stage
P(E|H) > P(E|Hc) E favors H over Hc If P(My lawn is wet | It rained overnight) >P(My
lawn is wet| It did not rain overnight) then ‘My
lawn is wet’ favors H ‘It rained overnight’
P(E|H) < P(E|Hc) E favors Hc over H If P(My lawn is wet | It rained overnight) <P(My
lawn is wet| It did not rain overnight) then ‘My
lawn is wet’ favors Hc ‘It did not rain overnight’

12/1/2016
Slide: 17
To go from Solution System Features to User Needs, we use Abductive
Reasoning through our imagination to generate an “Argument” much
similar to linking Evidence to Hypothesis.
From Solution System Features to User Needs

12/1/2016
Slide: 18
The Argument is
embedded in the
structure of a
Hierarchy of
Requirements: from
detailed Technical
Requirements and
Specifications, System
Requirements,
Business
Requirements, up to
Mission Requirements.
From Solution System Features to User Needs

12/1/2016
Slide: 19
Evidence to Hypothesis Solution System Feature to User Need
H: Hypothesis Set User Need = UN
E: Event relevant in an Inference about
H
Requirement= R : R satisfies UN
E*: Evidence that E occurred System Features = S : Evidence that R is
implemented
From E* to E : Credibility Stage From S to R : Verification Stage
P(E*|E) Hit probability P(S|R): is Requirement implemented?
P(E*|Ec) False positive probability P(S|Rc): is Requirement not
implemented?
From E to H : Relevance Stage From R to UN : Validation Stage
P(E|H) > P(E|Hc) E favors H over Hc P(R|UN) > P(R|UNc) : R satisfies UN over
UNc
P(E|H) < P(E|Hc) E favors Hc over H P(R|UN) < P(R|UNc) : R satisfies UNc
over UN

12/1/2016
Slide: 20
The Hierarchy of Requirements is
constructed to maximize:
P(R|UN) > P(R|UNc) : the
probability that the
Requirements Hierarchy (R)
satisfies User Needs (UN); which
is the primary index of
Requirements Validation
Requirements Validation

12/1/2016
Slide: 21
The Solution System Features
are crafted to maximize:
P(S|R) : the likelihood that
Requirements (R) are
implemented by the Solution
System Features (S); which is
the primary Index of System
Verification.
System Verification

12/1/2016
Slide: 22
Features included in Solution System = S
Features not included in Solution System = Sc
Current User Needs=UN
Not User Needs = UNc
Requirements Hierarchy= R
P(R|UN) > P(R|UNc) : R satisfies User Needs
P(R|UN) < P(R|UNc) : R does not satisfy User Needs
Validation Stage = Inductive Reasoning
P(S|R) : are Requirements implemented?
P(S|Rc) : are Requirements not implemented?
Verification Stage
Requirements Hierarchy is created through Abductive Reasoning
Deductive
Reasoning
Deductive
Reasoning
Reasoning types across the System Development
Life Cycle (SDLC)

12/1/2016
Slide: 23
We recommend viewing
the LinkedIn presentation
titled “ 6-Dimension
Business Model”
for an in-depth coverage
on how to assemble a
linked set of credibility
and relevance evidence
to transform Customer
Demands and
Relationships (User
Needs) into appropriate
and profitable Product
and Service offerings.
class EBMM Framework
WHATWHY
Business Policy
Policy Type
Mission
Vision
Principle
Directive
Business
Initiative/Program
Driver
Business Goal
Capability Road
Map
Charter/Legislation
Business
Strategy/Objective
Success
Metric/Measure
Influencer
Business Rules
and Facts
Customer Demand
and Relationship
Value
Proposition
RegulationCompetitive
Pressure
Business Trend
Competitive
Opportunity
Business Model
Assessment
Business
Judgement
Potential ImpactPotential Reward
Risk
Issues
StrengthWeakness Recommendation
of Change
WHO
Stakeholder
Governance
Body
Business Unit Business Alliance
and Partnership
Influencing
Organization
Market Segment
Business
Capability
Required
Competency
Asset
Product and
Service
Business
Requirement
Use Case or User
Story
Data Object
WHERE
Geography/
Locale
Distribution
Channels
HOW
Business Process / Activity
Application
System Interaction
Point
Application
Feature
Assessment
Metric
Process MetricKey Performance
Indicator
Finance and Revenue Model
EBMM-TRIADS(TM) (c) 2013-2015
Pragmatic Cohesion Consulting LLC , All
Rights Reserved
requires
describes
governs use of
described in
responds to
input to
evaluates
performs
measures
describes changes to
provides impetus for
Operates from
targets
quantifies
responsible for
governs
tracks success of
delivered through
enforces
generates
provided by
affect and
demand
tracks
drives
packages
implemented through
produces and consumes

12/1/2016
Slide: 24
Reasoning Examples
• The User Needs are similar to the Hypothesis set.
• The highest level of the Requirements Hierarchy such as
Mission Requirements, correspond to the particulars or the
evidence that we can deduce from the User Needs.

12/1/2016
Slide: 25
Reasoning Examples
• Example of AQUATIO drinking fountain:
– User Needs: A Drinking Fountain that does not splash water when
user drinks directly from it and that requires minimal bending of user’
s body when operated.
– Mission Requirements can de deduced from the formulation of use
cases describing the interaction of the user with the Drinking
Fountain in its expected operating environment(s).

12/1/2016
Slide: 26
Reasoning Examples
• In turn, the lowest level of the Requirements Hierarchy such
as the Technical Specifications resulting from design
activities, can be used to deduce the Solution System
Features.
”The fountain is shaped like a bowl and
can be pivoted up to four inches which
will considerably reduce the need to bend
over when drinking water from the
fountain. By pressing left side of the
fountain, cold water will start to flow and
pressing the right side will give you room
temperature water.”

12/1/2016
Slide: 27
• X has property G (we wish to know why)
• If entity A has particular relation R to any X, then that X has property G
• Thus, there is possibly some A that has relation R to X (which explains why
X has property G)
Reasoning Examples
Thagard’s “Existential Abduction” according to
Schum:
• System X has Goal G (we wish to know why)
• If entity A has particular relation R to any System X, then that
System X has Goal G
• Thus, there is possibly some A that has relation R to System X
(which explains why System X has Goal G)

12/1/2016
Slide: 28
Reasoning Examples
Thagard’s “Existential Abduction” according to
Schum:
• If entity A has particular relation R to any System X, then that
System X has Goal G
• Thus, there is possibly some A that has relation R to System X
(which explains why System X has Goal G)
• If entity A is a System Rule for[relation] any System X, then that
System X has Goal G
• Thus, there is possibly some A that is a System Rule for[relation]
System X (which explains why System X has Goal G)

12/1/2016
Slide: 29
Reasoning Examples
Motivation
(Why)
Process
(How)
Data
(What)
Contextual
(Scope)
[C1] System Goals [C2] System Functions [C3] List of things
important to the
System
Conceptual
(Business
Model)
[C4] System Rules
P(C4|C1) > P(C4|C1c)
[C5] System Processes
P(C5|C2) > P(C5|C2c)
[C6] System
Entities
P(C6|C3) > P(C6|C3c)
Logical
(System model)
support support support
support
support
P(C2|C1) > P(C2|C1c) P(C3|C1) > P(C3|C1c)

12/1/2016
Slide: 30
Motivation
(Why)
Process
(How)
Data
(What)
Contextual
(Scope)
[C1] System Goals
Provide drinkable Fountain
Water that does not splash
water when user requests
drinking directly from it and
that requires minimal
bending of user’ s body
when operated.
[C2] System
Functions
[C3] List of things
important to the
System
Conceptual
(Business Model)
[C4] System Rules [C5] System
Processes
[C6] System Entities
? ?
? ? ?

12/1/2016
Slide: 31
Motivation
(Why)
Process
(How)
Data
(What)
Contextual
(Scope)
[C1]
when operated.
[C2] [C3] List of things
important to the
System
Conceptual
(Business Model)
[C4] System Rules [C5] [C6]
drive
?
?
are supported by

12/1/2016
Slide: 32
Motivation
(Why)
Process
(How)
Data
(What)
Contextual
(Scope)
[C1]
when operated.
[C2] [C3]
-Water trajectory from its
source to its consumption
point
-Water purity
-Water splash level
-Water temperature
-Anatomy and physiology of
users
Conceptual
(Business Model)
[C4]
-User controls water on/off
flow
-A flow of water splashes
over a surface based on the
speed of the flow and the
angle with which it hits the
surface
-User drinks directly from
the fountain with his/her
mouth
[C5] [C6]
drive
are supported by

12/1/2016
Slide: 33
Motivation
(Why)
Process
(How)
Data
(What)
Contextual
(Scope)
[C1]
Provide drinkable Fountain Water
that does not splash water when
user requests drinking directly
from it and that requires minimal
bending of user’ s body when
operated.
[C2] System Functions [C3]
point
-Water purity
-Water splash level
-Water temperature
users
Conceptual
(Business Model)
[C4]
-User controls water on/off flow
-A flow of water splashes over a
surface based on the speed of
the flow and the angle with
which it hits the surface
-User drinks directly from the
fountain with his/her mouth
[C5] [C6]
drive
used by
?

12/1/2016
Slide: 34
Motivation
(Why)
Process
(How)
Data
(What)
Contextual
(Scope)
[C1]
that requires minimal bending
of user’ s body when
operated.
[C2]
-Dispense drinkable water
to user’s mouth when
requested
-Suppress water splashing
when operated by user
-Preserve user’s standing
body position during
operation
[C3]
point
-Water purity
-Water splash level
-Water temperature
users
Conceptual
(Business Model)
[C4]
-User controls water on/off
flow
-A flow of water splashes over
a surface based on the speed
of the flow and the angle with
which it hits the surface
-User drinks directly from the
fountain with his/her mouth
[C5] [C6]
?
System Processes
are supported by
govern

12/1/2016
Slide: 35
Motivation
(Why)
Process
(How)
Data
(What)
Contextual
(Scope)
[C1] System Goals
Provide drinkable
Fountain Water that does
not splash water when
user requests drinking
directly from it and that
requires minimal bending
operated.
[C2] System Functions
-Dispense drinkable water to user’s
mouth when requested
-Suppress water splashing when
operated by user
-Preserve user’s standing body
position during operation
[C3] things important to the
System
-Water trajectory from its source to
its consumption point
-Water purity
-Water splash level
-Water temperature
-Anatomy and physiology of users
Conceptual
(Business
Model)
[C4] System Rules
-User controls water
on/off flow
over a surface based on
the speed of the flow and
the angle with which it
hits the surface
mouth
-Controlling water on/off flow
-Routing fountain water
-Controlling water temperature
-Controlling distance between
water flow trajectory and user’s
mouth with minimal body bending
-Controlling water flow shape,
speed and angle of impact on
receiving surface
govern use of
?produce
are supported by

12/1/2016
Slide: 36
Motivation
(Why)
Process
(How)
Data
(What)
Contextual
(Scope)
[C1] System Goals
Provide drinkable
Fountain Water that does
not splash water when
user requests drinking
directly from it and that
requires minimal bending
operated.
[C2] System Functions
-Dispense drinkable water to user’s
mouth when requested
-Suppress water splashing when
operated by user
-Preserve user’s standing body
position during operation
[C3] Things important to the
System
-Water trajectory from its source to
its consumption point
-Water purity
-Water splash level
-Water temperature
-Anatomy and physiology of users
Conceptual
(Business
Model)
[C4] System Rules
-User controls water
on/off flow
over a surface based on
the speed of the flow and
the angle with which it
hits the surface
mouth
-Controlling water on/off flow
-Routing fountain water
-Controlling water temperature
-Controlling distance between water
flow trajectory and user’s mouth
with minimal body bending
-Controlling water flow shape,
speed and angle of impact on
receiving surface
-Users’ height range
-Water drinkable quality
-Water trajectories induced by water
flow shape and speed
-Angle between water flow and
receiving surface
-Water flow splash level
-Distances between water flow and
user’s mouth while standing
-User’s body bending angle per water
flow trajectories and user’s body
heights

12/1/2016
Slide: 37
References:
• “Enterprise Business Motivation Model (EBMM)
TRIADS™ –The Chemistry of Business Architecture
Alignment,” Koffi A.D., Journal of Enterprise
Architecture, volume 11, number 1, pp28-40 (2015)
• “A Model for Characterizing the Influence of the
Zachman Framework’s Enterprise Architecture
Perspectives,” Koffi A.D., Journal of Enterprise
Architecture, volume 6, number 2, pp30-47 (2010)
• “Structuring design Knowledge for Better Design
Synthesis”, Tomiyama T., International conference on
Engineering Design, August pp19-20 (2003)
• “Species of Abductive Reasoning in Fact
Investigation in Law," Schum D. ,Cardozo Law
Review, Vol 22, Nos 5 - 6, pp1645 -1681 (2001)
• “The engineering design of systems: models and
methods”, Buede D.M. , Wiley, New York (2000).
• "Probabilistic Reasoning and the Science of
Complexity," Shanteau, J., Mellors. B., Schum, D.
(Eds.) Decision Science and Technology, Kluwer
Academic Press, pp183-209 (1999)
• “Systems engineering and analysis” Blanchard B.S.
and Fabrycky W.J. , Prentice-Hall, Upper Saddle River,
NJ (1998)

12/1/2016
Slide: 38
Questions?

12/1/2016
Slide: 39
CAI Sponsors Proudly Sponsors
The IT Metrics & Productivity Institute
• Accelerating IT Success: News & Education: www.aits.org
• The Strategic CIO: www.thestrategiccio.com
• Calendar of LIVE daily webinars: www.itmpi.org/webinars
• HUGE repository of webinar recordings: www.itmpi.org/library
• Enjoy the Benefits of ITMPI Membership at: www.itmpi.org/subscribe
• Automatic Registration for Live Webinars
• Unlimited Free PDU and Recording Access for ONE YEAR
• Access to Over 1000+ PDUs for a Period of ONE YEAR
• Stay tuned for our awesome new mobile app, the Great IT Pro!

12/1/2016
Slide: 40
Easily Maintain Your PMP with
Unlimited Access To Over
1,000 PDU Approved Webinars
For One Low Yearly Price!
www.itmpi.org/subscribe

12/1/2016
Slide: 41
Hosted by:
Jessica Dahbour
ITMPI
Jessica_Dahbour@compaid.com
Didier Koffi
Principal Business Architect
Pragmatic Cohesion Consulting, LLC
didier@pragmaticohesion.com

Deductive, inductive, and abductive reasoning and their application in transforming user needs into a solution system

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Deductive, inductive, and abductive reasoning and their application in transforming user needs into a solution system

Similar to Deductive, inductive, and abductive reasoning and their application in transforming user needs into a solution system (20)

More from Pragmatic Cohesion Consulting, LLC

More from Pragmatic Cohesion Consulting, LLC (20)

Recently uploaded

Recently uploaded (20)

Deductive, inductive, and abductive reasoning and their application in transforming user needs into a solution system