The document outlines the concepts and methodologies of Obstacle Driven Development (ODD), emphasizing its connection to requirements analysis and safety integrity levels (SILs). It discusses the adaptation of traditional models, such as the spiral model and decision trees, to enhance requirements analysis and testing processes. Furthermore, it illustrates the creation of unit tests to ensure that product behaviors align with specified requirements through a structured approach.

1. Obstacle Driven Development
Extending Requirements Analysis 2
©odd.enterprises
26/02/2015

2. Obstacle Driven Development
26/02/2015 ©odd.enterprises 2

3. ODD Circle Model
26/02/2015 ©odd.enterprises 3

4. ODD Process
26/02/2015 ©odd.enterprises 4

5. Background
Ideas of Obstacle Driven Development (ODD) are based on
numerous development processes including:
• ISO V-model
• Test Driven Development
• ISO specifications
• Requirements analysis
• Agile principles
26/02/2015 ©odd.enterprises 5

6. About Requirements Analysis
Requirements analysis encompasses tasks that determine the
needs or conditions necessary for a new or altered product.
Tasks necessary for requirements analysis include:
• Analysing, documenting, validating and managing software or
system requirements
• Identify and resolve conflicting requirements of stakeholders
• Identifying business needs or opportunities using testable and
traceable processes
26/02/2015 ©odd.enterprises 6

7. Requirements Analysis 1
Requirements analysis spiral and
Safety Integrity Levels are adapted
to give ODD processes.
Requirements analysis is performed
in numerous ways
• Spiral model
• Use case analysis
• Safety integrity Levels (SILs)
26/02/2015 ©odd.enterprises 7

8. Requirements Analysis 2
A spiral model is superimposed
with an M-model and adaptions
made.
• Agreed Behaviours substitutes
Agreed Requirements
• Quality Assurance equivalent to
Testing
• Negotiation similar to Verification
26/02/2015 ©odd.enterprises 8

9. Requirements Analysis 3
Further adaption leads to an ODD
model for requirements analysis.
• Product, Consolidated
Requirements and Documents
are checkpoints
• Verification substituted for
Negotiation
• Validation substitutes Evaluation
• Testing substitutes Quality
Assurance
26/02/2015 ©odd.enterprises 9

10. ODD Analysis
Requirements analysis is adapted to
allow for ODD and combined with
the first stages of an M-model.
• Safety Integrity Levels used to
measure and process hazards
• Decision tree approach used to
create situations
• Verification and validation of
specification
26/02/2015 ©odd.enterprises 10

11. ODD M-model
Adding Solution and Production
stages of development results in an
ODD M-model.
• ODD process is linked from start
to finish, and beyond
• Verification and validation
between all stages
• Tests are ran as additions and
editing occurs
26/02/2015 ©odd.enterprises 11

12. ODD M-model Checkpoints 1
Checkpoints are determined for the
solution and production stages.
• Prototype created from
integrated solution
• Product is result of production
• Linked to other checkpoints
horizontally
26/02/2015 ©odd.enterprises 12

13. ODD M-model Checkpoints 2
Checkpoints allow linking and
testing of results to previous stages.
• Each checkpoint links another
• Prototype fulfils identified
requirements
• Product should behave as
described in documents
26/02/2015 ©odd.enterprises 13

14. Fire Triangle 1
A fire triangle is an educational tool
for understanding and preventing
fires.
• If the fire triangle is completed
then a fire will occur
• Preventing one situation from
occurring will prevent a fire
• Requirements often regard
preventing fires
26/02/2015 ©odd.enterprises 14

15. Fire Triangle 2
Using a reordered fire triangle it is
seen that components combine to
create a hazard.
• Process is adaptable to all fire
hazards and environments
• Extendible to any number of fire
hazard situations
• Components can be given SIL
ratings for Probability, Severity
and Controllability
26/02/2015 ©odd.enterprises 15

16. Fire Triangle 3
Reordering again gives a decision
tree for fire prevention.
• Investigated for requirements of
a situation
• Each branch is analysed and
processed
• Useful for any and all fire hazards
• To simplify oxygen is assumed
present
26/02/2015 ©odd.enterprises 16

17. Fire Triangle 4
Decision tree shows
the hazards of each
situation.
• Top branch ignites a
fire
• Next 2 branches are
fire hazards
• Each situation is
analysed separately
26/02/2015 ©odd.enterprises 17

18. Probability Tree 1
Probability trees measure likelihood
of an event occurring from a
defined situation.
• A common example is probability
of coin tosses
• Probability of heads occurring
assumed to be 50%
• Each branch gives an individual
situation
26/02/2015 ©odd.enterprises 18
Heads 50%
Heads 50%
Tails 50%
Tails 50%
Heads 50%
Tails 50%

19. Binomial Distribution 1
Binomial distributions determine
probability for any number of
events with 2 possible outcomes.
• Binomial process illustrates how
decision trees can be extended
• Potential use to model complex
interactions
26/02/2015 ©odd.enterprises 19

20. Binomial Distribution 2
Binomial distributions determines
probability for any number of
events with 2 possible outcomes.
• Decision trees can be extended
for infinite number of events
• Only used to model true or false
experiments
𝑃 𝑋 = 𝑘 =
𝑛
𝑘
𝑝 𝑘(1 − 𝑝) 𝑛−𝑘
𝑃 𝑋 = 𝑘 = Probability of Event
𝑘 = Number of Events
𝑛 = Number of Trials
26/02/2015 ©odd.enterprises 20

21. Probability Tree 2
Coin toss example is extended into
engineering by substituting system
components.
• Working component replaces
heads
• Failing component replaces tails
• Potential hazards of a series of
failures can be determined
26/02/2015 ©odd.enterprises 21
Component 1
Pass 99%
Component 2
Pass 98%
Component 2
Fail 2%
Component 1
Fail 1%
Component 2
Pass 98%
Component 2
Tails 2%

22. Binomial Distribution 3
Binomial distributions used to
determine probability for
components failing.
• Commonly used for measuring
probabilities in manufacturing
• Extendible to model failure in the
field
26/02/2015 ©odd.enterprises 22
Component 1
Pass 99%
Component 2
Pass 98%
Component 2
Fail 2%
Component 1
Fail 1%
Component 2
Pass 98%
Component 2
Tails 2%

23. Probability Tree 3
Probability trees are easily
extended to other situations.
• Coins may also land on their side
• Landing on sider assigned a
probability of 0.017 % (1 per
6000 tosses)
• Probability tree has exponentially
more branches
26/02/2015 ©odd.enterprises 23
Head ≈ 50%
Head ≈ 50%
Tails ≈ 50%
Side ≈
1 / 6000
Tails ≈ 50%
Head ≈ 50%
Tails ≈ 50%
Side ≈
1 / 6000
Side ≈
1 / 6000
Head ≈ 50%
Tails ≈ 50%
Side ≈
1 / 6000

24. Probability Tree 4
Probability trees can be used to
ensure all possible situations are
modelled.
• Systems have unknown states
between pass and fail
• Unknown states include loss of
communication or wear
• Unknown states investigated for
effects
26/02/2015 ©odd.enterprises 24
Component 1
Pass 98%
Component 2
Pass 96%
Component 2
Fail 2%
Component 2
Unknown 2%
Component 1
Fail 1%
Component 2
Pass 96%
Component 2
Fail 2%
Component 2
Unknown 2%
Component 1
Unknown 1%
Component 2
Pass 96%
Component 2
Fail 2%
Component 2
Unknown 2%

25. Safety Integrity Levels 1
Safety Integrity Levels (SILs) are
used to measure potential hazards
of a situation.
• Situation is analysed for
Probability, Severity and
Controllability
• Estimates for a risk of hazards
occurring from the situation
𝑆𝐼𝐿 = 𝑃 𝐸 ∗ 𝑆 𝐸 ∗ 𝐶 𝐸
𝑃 𝐸 = Probability of Event
𝑆 𝐸 = Severity of Event
𝐶 𝐸 = Controllability of Event
26/02/2015 ©odd.enterprises 25

26. Safety Integrity Levels 2
Safety Integrity Levels are used for a
wide range of safety critical
analysis.
• Probability is how likely a
situation will occur
• Severity is potential damage of a
situation
• Controllability is ability to effect
change in a situation
26/02/2015 ©odd.enterprises 26
Component
𝑆𝐼𝐿 = 𝑃 𝐸 ∗ 𝑆 𝐸 ∗ 𝐶 𝐸

27. Safety Integrity Levels 3
Coin toss example is extended to
provide example of SILs.
• Probability of result is different
for each coin
• Severity of outcome measured by
hazards
• Controllability determined by
who flips coin and stakes
26/02/2015 ©odd.enterprises 27

28. Safety Integrity Levels 4
Probability tree and SILs are
combined to form a decision tree.
• Measures added for severity and
controllability
• Each branch is a situation with
SIL ratings and requirements to
be found
• SIL ratings are applied and found
for each situation
26/02/2015 ©odd.enterprises 28

29. ODD Decision Tree 1
A decision tree creates situations
and processes requirements.
• Severity and Controllability are
added to each event
• Requirements are found with SIL
processes using branches
• Facilitates a unit testing approach
for situations
26/02/2015 ©odd.enterprises 29

30. ODD Decision Tree 2
Adding SIL components to a
Probability Tree allows requirement
identification from a decision tree.
• Structure is a branching
probability tree with SILs
• SILs are found by multiplying
along branches of a decision tree
26/02/2015 ©odd.enterprises 30

31. ODD Decision Tree 3
Processing resulting decision tree is
similar to a probability tree.
• SIL ratings processed by
multiplying probability, severity
and controllability
• SIL rating multiplied along
branches
• SIL result between 1 and 4, with
4 being best
26/02/2015 ©odd.enterprises 31
Component 1
Pass
P(P1)*S(P1)*C(P1)
Component 2
Pass
P(P2)*S(P2)*C(P2)
Component 2
Fail
P(F2)*S(F2)*C(F2)
Component 1
Fail
P(F1)*S(F1)*C(F1)
Component 2
Pass
P(P2)*S(P2)*C(P2)
Component 2
Fail
P(F2)*S(F2)*C(F2)

32. ODD Decision Tree 4
Using a decision tree and SILs gives
numerous advantages.
• Branches are used to ensure
predictable situations are found
• Extendible and adaptable to new
situations
• Each branch is a situation
• Situations are found from
combining component situations
26/02/2015 ©odd.enterprises 32
Component 1
Pass
Component 2
Pass
Situation A
Component 2
Fail
Situation B
Component 1
Fail
Component 2
Pass
Situation C
Component 2
Fail
Situation D

33. Processing Decision Trees
Situation A defines a situation
where both components have
passed.
Using a decision tree we can find a
SIL rating for the situation.
𝑆𝐼𝐿 𝐴
= 𝑃 𝑃1 ∗ 𝑆 𝑃1 ∗ 𝐶 𝑃1 ∗
𝑃 𝑃2 ∗ 𝑆 𝑃2 ∗ 𝐶(𝑃2)
Situation D defines a situation
where both components have
failed.
Using the decision tree we can find
a SIL rating for the situation.
𝑆𝐼𝐿 𝐷
= 𝑃 𝐹1 ∗ 𝑆 𝐹1 ∗ 𝐶 𝐹1 ∗
𝑃 𝐹2 ∗ 𝑆 𝐹2 ∗ 𝐶(𝐹2)
26/02/2015 ©odd.enterprises 33

34. ODD Decision Tree 5
Decision tree gives potential for an
infinite range of situations.
• Events can be comprehensively
modelled and extended
• New situations added as
branches
• Models complexity of expected
situations
• Software implementation
26/02/2015 ©odd.enterprises 34

35. ODD Decision Tree 6
Component 1
Pass
Component 2
Pass
Component 3
Pass
Component 3
Fail
Component 3
Unknown
Component 2
Fail
Component 3
Pass
Component 3
Fail
Component 3
Unknown
Component 3
Unknown
Component 3
Pass
Component 3
Fail
Component 3
Unknown
Component 1
Fail
Component 2
Pass
Component 3
Pass
Component 3
Fail
Component 3
Unknown
Component 2
Fail
Component 3
Pass
Component 3
Fail
Component 3
Unknown
Component 2
Unknown
Component 3
Pass
Component 3
Fail
Component 3
Unknown
Component 1
Unknown
Component 2
Pass
Component 3
Pass
Component 3
Fail
Component 3
Unknown
Component 2
Fail
Component 3
Pass
Component 3
Fail
Component 3
Unknown
Component 2
Unknown
Component 3
Pass
Component 3
Fail
Component 3
Unknown
26/02/2015 ©odd.enterprises 35
A decision tree to illustrate complexity of modelling situations and software will be necessary to
facilitate this. Modelled are 3 components with 3 different states: Pass, Fail and Unknown.

36. Creating Unit Tests 1
Unit testing is used to link
requirements with behaviours.
• Each branch represents a
situation which a behaviour
should cover
• Requirements are found from
situations
• Unit tests are created for each
branch of a decision tree
26/02/2015 ©odd.enterprises 36

37. Creating Unit Tests 2
Each requirement creates a test
which is solved by describing a
behaviour.
• Test is created to ensure
requirement is covered
• Specification describes all
expected behaviours of a product
• Allows cross examination of
behaviours against situations
26/02/2015 ©odd.enterprises 37

38. Creating Unit Tests 3
1. Requirement is chosen from
branch on a decision tree.
2. Behaviour verification test is
created directly from
requirement.
3. Behaviour is described to cover
requirement.
4. Behaviour is validated by
passing test.
5. Repeat for all requirements.
26/02/2015 ©odd.enterprises 38

39. Creating Unit Tests 4
Unit tests link situations and
requirements with behaviours
through creating and solving a test.
• Verification through creation of
test
• Validation through passing test
• Situations are combined to
produce complex situations
26/02/2015 ©odd.enterprises 39

40. Linking Tests 1
Each situation is linked to a
behaviour contained in a
specification.
• Behaviour A covers normal
operation
• Behaviour B and C cover single
failures of components
• Behaviour D covers total failure
of components
26/02/2015 ©odd.enterprises 40

41. Linking Tests 2
Each situation creates a unit test to
link analysis with specification.
• Diagrams shows various stages of
completeness
• Once unit test is passed it
becomes green
• Tests are implemented as a suite
and ran when editing occurs
26/02/2015 ©odd.enterprises 41

42. Linking Tests 3
Each situation is linked to a
behaviour contained in a
specification.
• Behaviour A covers normal
operation
• Behaviour B and C cover single
failures of components
• Behaviour D covers total failure
of components
26/02/2015 ©odd.enterprises 42

43. Linking Tests 4
When using a waterfall type
development then analysis is
complete when all tests are passed.
• Tests run when any changes in
analysis or specification
• Ensures expected situations are
covered
• Potential for infinite situations
26/02/2015 ©odd.enterprises 43

44. ODD Combined Model
26/02/2015 ©odd.enterprises 44
The testing process is
similar throughout
ODD with adaptions
between stages.
• Each set of traffic
light demonstrates
unit testing
• Tests begin with an
element from
previous stage

45. Linking Tests 5
Tests link product features with
analysis through utilisation and
elicitation.
• Requirements are found from
analysing each feature
• Each feature is a single aspect of
the product
• Unit testing is applied
26/02/2015 ©odd.enterprises 45

46. Linking Tests 6
Requirements analysis is the most
difficult and important stage to link.
• Utilisation and elicitation should
concern situations resulting from
product features
• Customers are involved for
utilisation and elicitation
• Each situation encountered is
covered by a requirement
26/02/2015 ©odd.enterprises 46

47. Further Information and Questions
• Website
• Presentations
• Facebook
• Twitter
• Email
26/02/2015 ©odd.enterprises 47

48. Legal Stuff
References
Test Driven Development for Embedded C
James Grenning, 2011
Requirements Analysis
http://en.wikipedia.org/wiki/Requirements_analysis
Safety Integrity Level
http://en.wikipedia.org/wiki/Safety_Integrity_Level
Decision Tree
http://en.wikipedia.org/wiki/Decision_tree
Requirements Spiral Model
www.engineering.uiowa.edu/~kuhl/SoftEng/Slides4.pdf
Unit Testing
http://en.wikipedia.org/wiki/Unit_testing
Disclaimer
The ODD M-model and associated processes are provided by odd.enterprises and may be
used for any purpose whatsoever.
The names odd.enterprises and associated logos should not be used in any representation,
advertising, publicity or other manner whatsoever to endorse or promote any entity that
adopts or uses the model and/or associated processes.
odd.enterprises does not guarantee to provide support, consulting, training or assistance of
any kind with regards to the use of the model and/or processes including any updates.
You agree to indemnify odd.enterprises and its affiliates, officers, agents and employees
against any claim or demand including reasonable solicitors fees, related to your use,
reliance or adoption of the model and/or processes for any purpose whatsoever.
The model is provided by odd.enterprises “as is” and any express or implied warranties,
included but not limited to the implied warranties of merchantability and fitness for a
particular purpose are expressly disclaimed.
In no event shall odd.enterprises be liable for any damages whatsoever, including but not
limited to claims associated with the loss of data or profits, which may result from any
action in contract, negligence or other tortious claim that arises out of or in connection with
the use or performance of the model.
26/02/2015 ©odd.enterprises 48