Presentation by my colleague Prof Jon Holt on the Benefits & Challenges of MBSE. You can watch the full presentation on the INCOSE UK YouTube channel

2. Benefits and challenges of MBSE
– I know an old lady
By Prof Jon Holt
Technical Director, INCOSE UK
Jon.holt@scarecrowconsultants.co.uk
Copyright © 2015

3. Overview
1. Realising MBSE
2. I know an Old Lady
3. Conclusions

4. 1: Realising MBSE
«block»
Person
«block»
Process
«block»
MBSE
«block»
Tool
1..* 1..*
1..*
enables
1..* 1..*
drives
1..*
1..*

5. 2: I Know an Old Lady …

6. … Who Swallowed a Fly …..

7. … I Don’t Know Why She Swallowed a
Fly
• Knowing ‘why’ is essential
• ‘Why’ will depend on context
– Different stakeholders have different needs
– Different stakeholders want different benefits

8. Realising MBSE Benefits
«block»
Person
«block»
Process
«block»
MBSE
«block»
Tool
«block»
Benefit
«block»
Stakeholder Role
1..* 1..*
1..*
enables
1..*
1..*
must realise
1..*
1..*
drives
1..*
1..*

9. Typical MBSE Stakeholder Roles
«block»
Stakeholder Role
«block»
Customer
«block»
External
«block»
Supplier
«block»
User
«block»
Operator
«block»
System Sponsor
«block»
Standard
«block»
Manager
«block»
Engineer
«block»
MBSE Sponsor
«block»
Benefit
1..*
must realise
1..*

10. Engineer ContextEngineer Context
Improve system
development
Improve consistency
Improve automation
Make approach more
efficient
Manage complexity
Increase
understanding
Improve
communication
... for testing
... for artefact
generation
... for model checking
improve tool
interoperability
MBSE Sponsor
Manager
«include»
«constrain»
«constrain»
«constrain»
«include»
«include»
«constrain»

11. MBSE Sponsor Context
MBSE Sponsor Context
Increase value of
business
Increase sales Increase quality
Invest in MBSE
Demonstrate ROI
Operator
User
Engineer
«include»
«constrain»
«constrain»
«include»

12. Identified Benefits of MBSE
«block»
Time
«block»
Resource
«block»
Money
«block»
Quality Attribute
«block»
Safety
«block»
Security
«block»
Compliance
«block»
Return on
Investment
«block»
Efficiency
«block»
Consistency
«block»
Complexity
Management
«block»
Communication
«block»
Re-use
«block»
Tool Interoperability
«block»
Automation
{incomplete}
MBSE

13. I Know an Old Lady Who Swallowed a
Spider …

14. … That Wriggled and Jiggled About
Inside Her
• Look for tried and tested solutions
• For flies, this is a spider
• For MBSE, this is:
– Standards
– Architecture frameworks
– Modelling notations
– Processes
– Methodologies
– More staff
– Etc.

15. Example Solutions – Architectures
• Consider the following examples:
– MODAF/DoDAF/NAF
– Zachman
– ISO 42010 (‘Systems and software Engineering -
Architecture description’)
• What are you trying to do:
– Development?
– Acquisition?
– Enterprise Architecture?

16. Visualising Architecture

17. I Know an Old Lady Who Swallowed a
Bird/Cat/Dog …

18. … How Absurd … Imagine That … What
a Hog
• Need to understand and control use of
techniques
– Shows no understanding of systems engineering
– Shows no understanding of own competence
• Need common language:
– In terms of spoken language (e.g. SysML)
– In terms of domain-specific language (e.g. an
Ontology)

19. Example of Common Spoken Language
- SysML

20. Example of Common Domain
Language – The MBSE Ontology
«block»
Viewpoint
Element
«block»
Architectural
Framework
«block»
Architecture
«block»
Ontology
«block»
Ontology Element
«block»
View
«block»
View Element
«block»
Viewpoint
«block»
Rule
properties
ID : Text
Description : Text
«block»
Enabling System
«block»
Constituent
System
«block»
System Element
«block»
System Context
«block»
System of
Interest
«block»
System of
Systems
«block»
System
«block»
Virtual
«block»
Collaborative
System
«block»
Directed System
«block»
Acknowledged
System
«block»
Product
«block»
Service
«block»
Activity
«block»
Artefact
«block»
Process
«block»
Process
Execution Group
«block»
Resource
«block»
Stakeholder Role
«block»
Context
«block»
Use Case
«block»
Level
«block»
Competence
«block»
Competency
«block»
Competency
Scope
«block»
Competency
Profile
«block»
Person
«block»
Life Cycle
«block»
Life Cycle
Interaction
«block»
Life Cycle
Interaction Point
«block»
Life Cycle Model
«block»
Gate
«block»
Stage
«block»
Project
«block»
Programme
«block»
Organisational
Unit
«block»
Organisation
«block»
Concern
«block»
Need
«block»
Source Element
«block»
Need Description
«block»
Scenario
«block»
Capability
«block»
Goal«block»
Requirement
«block»
Stakeholder
Context
«block»
Project Context
«block»
Organisational
Context
«block»
Semi-formal
Scenario
«block»
Formal Scenario
«block»
Process Context
1 requires
1
1..*
1
1..*
is elicited from
1..*
1..*
describesmeasured
1
1..* 1
{incomplete}
1..*
describes the evolution of
1
1
describes
1
1
is related to
0..*
1..*
is executed during
1
1
shows the order of execution of1..*
1..*
represents the need for
1
1
interacts with
1..*
1..*
runs
1..*
1
1..*
describes the context of
1..*
1..*
describes
1..*
1..*
interacts with
1
1..*
describestheevolutionof
1
1
produces
1..*
1
is realised as
1..*
1
describes abilities of
1
1..*
1
1..*
1
1..*
corresponds to
1
1..*
1
1..*
1..*
shows behaviour of
1
1..*
validates
1..*
1..*
1
1..*
1
1..*
describes the need for
1
1..*
visualises
1
1
1..*produces/consumes
1..*
1
assesses the execution of
1
1
represents the need for
1
1..*
describes desired
1
1..*
1
1..*
1
1
interacts with
1..*
1..*
is needed to deliver 1
1..*
uses elements from
1
1..*
is executed during
1
1..*holds1..* 1..*
enables
1..*
1
is held at
1
1..*
constrains
1
1..*
conforms to
1
1..*
1
describes interactions between
1
1..*
meets
1..*
1..*
interacts with
1
1
describes structure of
1
1..*
realises
1..*
1
interfaces with
1..*
1..*
0..1
1
is assessed against
1
1
interacts with
1..*
1
represents the need for
1..*
1..*
constrains
1..*
1
is responsible for
1..*
1
consumes
1
exhibits
1
1..*
1
1..*
1

21. Focus on Architecture
«block»
Viewpoint Element
«block»
Architectural Framework
«block»
Architecture
«block»
Ontology
«block»
Ontology Element
«block»
View
«block»
View Element
«block»
Viewpoint
«block»
Rule
«block»
System
1..*
1
1..*
describes
1..*
1..*
1
1..*
corresponds to
1
1
is related to
0..*
1..*
1
1
1
1..*
1
1
describes structure of
1
1..*
constrains
1
1..*
11..*
uses elements from
1
1..*
conforms to
1
1..*
visualises
1

22. Focus on Need
«block»
Rule
«block»
Context
«block»
Use Case
«block»
System Context
«block»
Concern
«block»
Need
«block»
Source Element
«block»
Need Description
«block»
Scenario
«block»
Capability
«block»
Goal
«block»
Requirement
«block»
Stakeholder
Context
«block»
Project Context
«block»
Organisational
Context
«block»
Semi-formal
Scenario
«block»
Formal Scenario
«block»
Process Context
1..*
constrains
1..*
1..*
validates
1..*
1..*
is needed to deliver 1
1..*
is elicited from
1..* 1..*
describes the context of
1..*
1..*
traces to
1..*
1
describes
1
{incomplete}
1..* meets
1..*
1
is related to
0..*
1
is related to
0..*

23. I Know an Old Lady Who Swallowed a
Goat/Cow …

24. … She Opened Her Throat … I Don’t
Know How
• Complete chaos!
– Lost sight of original goals
– No concept of relationships between techniques
• The MBSE Ontology drives the implementation of
MBSE
– Basis for framework and associated views
– Defines how views may be visualised (informs notation)
– Allows understanding and definition of associated
processes
– Allows understanding and definition of associated
competence
– Provides valuable input into tool assessment

25. Example View Based on the MBSE
Ontology
«block»
Rule
«block»
Context
«block»
Use Case
«block»
System Context
«block»
Concern
«block»
Need
«block»
Source Element
«block»
Need Description
«block»
Scenario
«block»
Capability
«block»
Goal
«block»
Requirement
«block»
Stakeholder
Context
«block»
Project Context
«block»
Organisational
Context
«block»
Semi-formal
Scenario
«block»
Formal Scenario
«block»
Process Context
1..*
constrains
1..*
1..*
validates
1..*
1..*
is needed to deliver 1
1..*
is elicited from
1..* 1..*
describes the context of
1..*
1..*
traces to
1..*
1
describes
1
{incomplete}
1..* meets
1..*
1
is related to
0..*
1
is related to
0..*
«block,rule»
ACRE01
notes
Each Source Element in the Source
Element View must be traceable to one
or more Need Description in the
Requirement Description View.
«block,rule»
ACRE02
notes
Each Need Description in the
Requirement Description View must be
traceable to one or more Source
Element in the Source Element View.
«block,rule»
ACRE03
notes
Rules, when they exist, must apply to a
Need Description.
«block,rule»
ACRE04
notes
Rules, when they exist, must apply to a
Need Description.
«block,rule»
ACRE05
notes
Each Need Description must be related
to at least one Use Case.
«block,rule»
ACRE06
notes
The Need Description Views must relate
to a Requirement Context View.
«block,rule»
ACRE07
notes
Each Need Description must have a full
set of attributes defined.
«block,rule»
ACRE08
notes
Each Rule must apply to at least one
Need Description attribute or the Need
Description itself.
«block,rule»
ACRE09
notes
Each Need Description may be
constrained by zero or more Rules.
«block,rule»
ACRE10
notes
Each Requirement Context View must
have a related element on a Context
Definition View that defines the
Context.
«block,rule»
ACRE11
notes
Each Use Case must be related to at
least one Need Description.
«block,rule»
ACRE12
notes
Each and every Need Description must
have at least one Use Case.
«block,rule»
ACRE13
notes
Each Stakeholder Role on the
Requirement Context View must have an
associated element form a Context
Definition View, such as a Stakeholder
Role or System Element.
«block,rule»
ACRE14
notes
Each Context Definition View must be
related to at least on Requirement
Context View.
«block,rule»
ACRE15
notes
Each Use Case must be related to either
another Use Case or a Stakeholder Role.
«block,rule»
ACRE16
notes
Each Use Case must have at least one
Validation View associated with it.
«block,rule»
ACRE17
notes
Each element in each Context Definition
View may define an individual
Requirement Context View.
«block,rule»
ACRE18
notes
Each element on a Stakeholder Context
Definition View, such as a Stakeholder
Role or System Element, may appear as a
Stakeholder Role on a Requirement
Context View.

26. Example View Based on the MBSE
Ontology
«block»
Rule
«block»
Context
«block»
Use Case
«block»
System Context
«block»
Concern
«block»
Need
«block»
Source Element
«block»
Need Description
«block»
Scenario
«block»
Capability
«block»
Goal
«block»
Requirement
«block»
Stakeholder
Context
«block»
Project Context
«block»
Organisational
Context
«block»
Semi-formal
Scenario
«block»
Formal Scenario
«block»
Process Context
1..*
constrains
1..*
1..*
validates
1..*
1..*
is needed to deliver 1
1..*
is elicited from
1..* 1..*
describes the context of
1..*
1..*
traces to
1..*
1
describes
1
{incomplete}
1..* meets
1..*
1
is related to
0..*
1
is related to
0..*
MBSE Champion
Requirement Engineer
Tester
Standard
Requirement Manager
Customer
Support capture of
needs
Support capture of
requirements
Support capture of
capabilities Support capture of
goals
Must be model-based Comply with standards
Identify source of
needs
Ensure consistent style
Define validation
approach
Consider needs in
context
Identify contexts
AF Framework Context
«constrain» «constrain»
«include»
«constrain»
«include»«include»
«constrain»

27. I know an old lady who swallowed a
horse …

28. … She’s Dead, of Course!…

29. 2. Conclusions
• MBSE requires:
– People, process and tools
• Essential concerns:
– Understand why and the benefits
– Do not apply techniques blindly
• Getting it right includes:
– Have a solid basis for MBSE – use of MBSE Ontology
• Getting it wrong results in:
– Dead bodies
– Horse dung
Copyright © 2015 28

30. Want to know more?
Copyright © 2015 29
Jon.holt@scarecrowconsultants.co.uk