odd: extending requirements analysis 2
TRANSCRIPT
![Page 1: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/1.jpg)
Obstacle Driven Development
Extending Requirements Analysis 2
©odd.enterprises
26/02/2015
![Page 2: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/2.jpg)
Obstacle Driven Development
26/02/2015 ©odd.enterprises 2
![Page 3: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/3.jpg)
ODD Circle Model
26/02/2015 ©odd.enterprises 3
![Page 4: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/4.jpg)
ODD Process
26/02/2015 ©odd.enterprises 4
![Page 5: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/5.jpg)
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
![Page 6: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/6.jpg)
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
![Page 7: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/7.jpg)
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
![Page 8: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/8.jpg)
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
![Page 9: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/9.jpg)
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
![Page 10: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/10.jpg)
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
![Page 11: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/11.jpg)
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
![Page 12: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/12.jpg)
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
![Page 13: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/13.jpg)
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
![Page 14: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/14.jpg)
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
![Page 15: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/15.jpg)
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
![Page 16: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/16.jpg)
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
![Page 17: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/17.jpg)
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
![Page 18: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/18.jpg)
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%
![Page 19: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/19.jpg)
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
![Page 20: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/20.jpg)
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
![Page 21: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/21.jpg)
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 1Pass 99%
Component 2Pass 98%
Component 2Fail 2%
Component 1Fail 1%
Component 2Pass 98%
Component 2Tails 2%
![Page 22: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/22.jpg)
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 1Pass 99%
Component 2Pass 98%
Component 2Fail 2%
Component 1Fail 1%
Component 2Pass 98%
Component 2Tails 2%
![Page 23: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/23.jpg)
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
![Page 24: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/24.jpg)
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 1Pass 98%
Component 2Pass 96%
Component 2Fail 2%
Component 2Unknown 2%
Component 1Fail 1%
Component 2Pass 96%
Component 2Fail 2%
Component 2Unknown 2%
Component 1Unknown 1%
Component 2Pass 96%
Component 2Fail 2%
Component 2Unknown 2%
![Page 25: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/25.jpg)
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
![Page 26: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/26.jpg)
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
𝑆𝐼𝐿 = 𝑃 𝐸 ∗ 𝑆 𝐸 ∗ 𝐶 𝐸
![Page 27: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/27.jpg)
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
![Page 28: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/28.jpg)
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
![Page 29: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/29.jpg)
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
![Page 30: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/30.jpg)
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
![Page 31: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/31.jpg)
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 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)
![Page 32: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/32.jpg)
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 1Pass
Component 2Pass
Situation A
Component 2Fail
Situation B
Component 1Fail
Component 2Pass
Situation C
Component 2Fail
Situation D
![Page 33: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/33.jpg)
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
![Page 34: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/34.jpg)
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
![Page 35: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/35.jpg)
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
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.
![Page 36: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/36.jpg)
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
![Page 37: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/37.jpg)
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
![Page 38: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/38.jpg)
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
![Page 39: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/39.jpg)
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
![Page 40: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/40.jpg)
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
![Page 41: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/41.jpg)
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
![Page 42: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/42.jpg)
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
![Page 43: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/43.jpg)
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
![Page 44: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/44.jpg)
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
![Page 45: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/45.jpg)
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
![Page 46: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/46.jpg)
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
![Page 47: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/47.jpg)
Further Information and Questions
• Website
• Presentations
26/02/2015 ©odd.enterprises 47
![Page 48: ODD: Extending Requirements Analysis 2](https://reader034.vdocuments.mx/reader034/viewer/2022051213/55c58175bb61ebd95d8b488a/html5/thumbnails/48.jpg)
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.
26/02/2015 ©odd.enterprises 48