ODD: Extending Requirements Analysis 1.3

Obstacle Driven DevelopmentExtending

Requirements

Analysis 1.3

Obstacle Driven Development

27/04/2016 ©odd.enterprises 2

ODD Circle Model


ODD Process


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


About Requirements Analysis

Requirements analysis determine needs or conditions necessary for a new or altered product.

Tasks 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


Requirements Analysis 1

• Requirements analysis is performed in numerous ways:

– Spiral model

– Use case analysis

– Safety integrity Levels (SILs)

• Requirements analysis spiral is adapted to an ODD process


Requirements Analysis 2


Requirements Analysis Adaptions 1

Spiral model is superimposed with an M-model and adapted.

• Agreed Behaviours substitutes Agreed Requirements

• Quality Assurance equivalent to Testing

• Negotiation similar to Verification

– Continues on next slide


Requirements Analysis Adaptions 2

Spiral model is superimposed with an M-model and adapted.

• Verification substituted for Negotiation

• Validation substitutes Evaluation

• Testing substitutes Quality Assurance


ODD Analysis

Requirements analysis combines with Specification in an inverted V-model.

• Tree diagram approach creates situations from events

• Safety Integrity Levels measure and process situations into hazards

• Checkpoints for Product, Consolidated Requirements and Documents


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


Fire Triangle 1

Fire triangles are for understanding and preventing fires.

• If a fire triangle is completed then a fire will occur

• Preventing one component will prevent a fire

• Requirements often regard preventing fires


Fire Triangle 2

We reorder a fire triangle to see how events create a hazard.

• Process is adaptable to all fire hazards and environments

• Extendible to any number of fire hazard situations

• Events given SIL ratings for Probability, Severity and Controllability


Fire Triangle 3

Reordering again gives a tree diagram for fire prevention.

• Branches each describe a single situation to be solved

• Each branch is analysed and processed for requirements

• Useful for any fire prevention

Note: Oxygen is assumed present


Fire Triangle 4

Tree diagrams show the hazards of each situation.

• Top branch ignites a fire

• Next 2 branches are fire hazards

• Last branch has no fire hazard

• Each situation is analysed separately


Fire Triangle 5

We link a Specification to Analysis to ensure each situation has an appropriate behaviour.

• Expected situations are described and assigned a behaviour

• Linking situations with a behaviour ensure coverage

• Specification is theoretical and/or simulations


Probability Tree 1

Probability trees measure likelihood of an event occurring from a defined situation.

• Common example is probability of coin tosses

• Probability of heads occurring assumed to be 50%

• Each branch gives an individual situation


Heads 50%

Heads 50%

Tails 50%

Tails 50%

Heads 50%

Tails 50%

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


Component 1Pass 99%

Component 2Pass 98%

Component 2Fail 2%

Component 1Fail 1%

Component 2Pass 98%

Component 2Tails 2%

Probability Tree 3

Probability trees easily extend to other situations.

• Coins may also land on their side

• Landing on side assigned a probability of 0.017 % (1 per 6000 tosses)

• Probability tree has exponentially more branches

• Unlikely situations must be considered


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

Probability Tree 4

Probability trees ensure all expected situations are modelled.

• Systems have unknown states between pass and fail

• Unknown states include loss of communication or wear

• Unknown states investigated for effects


Component 1Pass 98%

Component 2Pass 96%

Component 2Fail 2%

Component 2Unknown 2%

Component 1Fail 1%

Component 2Pass 96%

Component 2Fail 2%



Component 2Pass 96%

Component 2Fail 2%


Safety Integrity Levels 1

Safety Integrity Levels (SILs) help measure and process hazards of a situation into requirements.

• Situation analysed for Probability, Severity and Controllability

• Estimates risk of hazards resulting from a situation

• Allow requirements definition and assign priorities

𝑆𝐼𝐿 = 𝑃 𝐸 ∗ 𝑆 𝐸 ∗ 𝐶 𝐸

𝑃 𝐸 = Probability of Event

𝑆 𝐸 = Severity of Event

𝐶 𝐸 = Controllability of Event



Safety Integrity Levels are applied for 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


Situation

𝑆𝐼𝐿 = 𝑃 𝐸 ∗ 𝑆 𝐸 ∗ 𝐶 𝐸


Coin toss example is extended to provide example of SILs.

• Probability of result is different for each coin

• Severity of outcome measured by hazards – i.e. Stakes

• Controllability determined by who flips coin


Tree Diagram and Safety Integrity Levels

Tree diagram and SILs combine to form a SIL tree diagram.

• Measures for severity and controllability

• Branches describe a situation with SIL ratings

• SIL ratings are applied and found for each situation

• Requirements from SIL ratings


SIL Tree Diagram 1

SIL tree diagram creates situations from events and processes requirements.

• Severity and Controllability are added to each event

• Requirements found from SIL ratings using branches

• Allows a unit testing approach for situations and requirements


SIL Tree Diagram 2

Adding SIL components to a Probability Tree allows requirement identification and processing.

• Branching tree with SIL ratings for events

• SILs found by multiplying along branches of SIL tree

• Each situation given SIL rating to determine requirements


SIL Tree Diagram 3

Processing a SIL tree diagram is very similar to a probability tree.

• SIL ratings processed by multiplying probability, severity and controllability

• SIL rating multiplied along branches for each situation

• SIL result between 1 and 4, with 4 being best


Component 1Pass

P(P1)*S(P1)*C(P1)

Component 2Pass

P(P2)*S(P2)*C(P2)

Component 2Fail

P(F2)*S(F2)*C(F2)

Component 1Fail

P(F1)*S(F1)*C(F1)

Component 2Pass

P(P2)*S(P2)*C(P2)

Component 2Fail

P(F2)*S(F2)*C(F2)

SIL Tree Diagram 4

Using a SIL tree diagram gives numerous advantages.

• Branches ensure all expected situations are identified

• Extendible and adaptable to new situations by adding events

• Each branch is a situation

• New situations found from adding new events


Component 1Pass

P(P1)*S(P1)*C(P1)

Component 2Pass

P(P2)*S(P2)*C(P2)

Component 2Fail

P(F2)*S(F2)*C(F2)

Component 1Fail

P(F1)*S(F1)*C(F1)

Component 2Pass

P(P2)*S(P2)*C(P2)

Component 2Fail

P(F2)*S(F2)*C(F2)

Processing SIL Tree Diagrams

Situation A defines a situation where both components have passed.

Using a SIL tree diagram 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 tree diagram we can find a SIL rating for the situation.

𝑆𝐼𝐿 𝐷= 𝑃 𝐹1 ∗ 𝑆 𝐹1 ∗ 𝐶 𝐹1 ∗𝑃 𝐹2 ∗ 𝑆 𝐹2 ∗ 𝐶(𝐹2)


SIL Tree Diagram 5

Tree diagrams give potential for an infinite range of situations.

• Events are modelled and extended

• Situations found through events and branches

• Models complexity of expected situations

• Helps code software and hardware branches


SIL Tree Diagram 6

Component 1Pass

Component 2Pass

Component 3 Pass

Component 3 Fail

Component 3 Unknown

Component 2Fail

Component 3 Pass

Component 3 Fail

Component 3 Unknown

Component 3Unknown

Component 3 Pass

Component 3 Fail

Component 3 Unknown

Component 1 Fail

Component 2Pass

Component 3 Pass

Component 3 Fail

Component 3 Unknown

Component 2 Fail

Component 3 Pass

Component 3 Fail

Component 3 Unknown

Component 2Unknown

Component 3 Pass

Component 3 Fail

Component 3 Unknown

Component 1Unknown

Component 2 Pass

Component 3 Pass

Component 3 Fail

Component 3 Unknown

Component 2Fail

Component 3 Pass

Component 3 Fail

Component 3 Unknown

Component 2Unknown

Component 3 Pass

Component 3 Fail

Component 3 Unknown


Tree diagram illustrates complexity of modelling situations and software is necessary to facilitate. Modelled are 3 components with 3 different states: Pass, Fail and Unknown; giving 27 separate situations.

Creating Unit Tests 1

Requirements linked with behaviours through creating unit tests.

• Requirements are assigned a theoretical and/or simulated behaviour

• Requirements found from SIL processing of situations

• Unit test created for each branch of to ensure coverage



Each requirement creates a test which is solved with an appropriate behaviour.

• Test created to ensure requirement is covered

• Specification describes all expected behaviours of a product

• Allows cross examination of behaviours against situations



Unit tests link situations with behaviours through creating and solving a test.

• Verification is creation of a test

• Validation is passing a test

• Events combined to produce complex situations

• Appropriate behaviours specified to cover situations



1. Requirement chosen from branch.

2. Verification test created from requirement.

3. Behaviour described to cover requirement.

4. Behaviour validated by test.

5. Integrate and refactor behaviour.

6. Repeat for all requirements.


Linking Tests 1

Situations are linked to behaviours contained in a Specification.

• Situation A covered by normal behaviour

• Situation B and C require warnings to the user

• Situation D covers total failure of components and shuts down


Linking Tests 2

Situations are assigned 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


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


Linking Tests 4

Specification 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


Linking Tests 5

Tests link features and functions with analysis through utilisation and elicitation.

• We test whether a product is correct by asking customers

• Requirements found from analysing features and functions

• Functions and feature are single aspects of a product


Linking Tests 6

Unit testing for Analysis is applied to all features and functions

• Utilisation and elicitation concern situations of product features

• Customers are involved for utilisation and elicitation

• Situation created by a feature are covered by a requirement



1. Feature or function chosen from Production.

2. Utilisation test created for feature.

3. Product utilised by customers to identify situations.

4. Elicitation of utilisation validated by test.

5. Process identified requirements.

6. Repeat for all features and functions.


ODD Combined Model


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

ODD Continuous Process

• Process repeats for continuous improvement

• Further stages may be added as needed

• Proceed clockwise through each stage


ODD Materials

ODD is explained in further presentations.

• Obstacle Driven

Development

• ODD: Extending TDD

• ODD: Extending a

Specification

• ODD: Extending V-models

• ODD: Requirements Analysis

• ODD Is Not Agile or

Waterfall

ODD Is Not Agile or

Waterfall

Obstacle Driven Development

ODD: Requirements

Analysis

ODD: Extending a Specification

ODD: Extending V-models

ODD: Extending TDD


http://www.odd.enterprises/obstacle-driven-development.html

http://www.odd.enterprises/odd-extending-tdd.html

http://www.odd.enterprises/odd-specification.html

http://www.odd.enterprises/odd-extending-v-models.html

http://www.odd.enterprises/odd-requirements-analysis.html

http://www.odd.enterprises/odd-requirements-analysis.html

Further Information and Questions

• odd.enterprises

• ODD Presentations

• ODD Facebook

• ODD Twitter

• Email


http://www.odd.enterprises/home.html

http://www.odd.enterprises/odd-presentations.html

https://www.facebook.com/odd.enterprises

https://twitter.com/odd_enterprises

mailto:[email protected]

Legal Stuff

ReferencesTest 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

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


http://en.wikipedia.org/wiki/Requirements_analysis

http://en.wikipedia.org/wiki/Safety_Integrity_Level

http://en.wikipedia.org/wiki/Decision_tree

http://www.engineering.uiowa.edu/~kuhl/SoftEng/Slides4.pdf

http://en.wikipedia.org/wiki/Unit_testing

ODD: Extending Requirements Analysis 1.3

Engineering