Download pdf - ODD: Extending Requirements Analysis 2

Obstacle Driven Development

Extending Requirements Analysis 2

©odd.enterprises

26/02/2015

Obstacle Driven Development

26/02/2015 ©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 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


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)



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



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


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


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


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


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


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


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


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


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


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


Heads 50%

Heads 50%

Tails 50%

Tails 50%

Heads 50%

Tails 50%

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



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


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%


Binomial distributions used to determine probability for components failing.

• Commonly used for measuring probabilities in manufacturing

• Extendible to model failure in the field


Component 1Pass 99%

Component 2Pass 98%

Component 2Fail 2%

Component 1Fail 1%

Component 2Pass 98%

Component 2Tails 2%

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


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


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) 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



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


Component

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


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



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


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


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


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


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)

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


Component 1Pass

Component 2Pass

Situation A

Component 2Fail

Situation B

Component 1Fail

Component 2Pass

Situation C

Component 2Fail

Situation D

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)


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


ODD Decision Tree 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


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.

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



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



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


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


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


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


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

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


ODD Combined Model


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

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


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


Further Information and Questions

• Website

• Presentations

• Facebook

• Twitter

• Email


http://odd.enterprises/

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