OBSE - Ontology Based System Engineering

Ontology Based Systems Engineering
Nordic Systems Engineering Tour – April, 2013
www.reusecompany.com

2 April 15th,16th, 17th 2013Nordic Systems Engineering Tour
Juan Llorens
CTO in The Reuse Company
Professor at Carlos III University
Technical Director of INCOSE’s Spanish Chapter
juan.llorens@reusecompany.com

Fundamentals of
Ontology Based Systems Engineering (OBSE)

Need of knowledge for better Systems Engineering
 The “smarter” we want systems engineering to be, the more dependent on
“semantic” knowledge shall it be.
 For Requirements Management and Engineering
Writing Management Engineering
0% 25% 50% 75% 100%
Semantics

“semantic” knowledge shall it be. Challenges for Requirements Quality Mgmt.
(source: Gauthier Fanmuy - the RAMP project: - AFIS)

“semantic” knowledge shall it be.
0% 25% 50% 75% 100%
Semantics
 Knowledge must be represented within a knowledge structure (KOS)
 from internal representations to glossaries, to …., to ontologies)
 The selection of the knowledge structure allows different possibilities to the
organization

Knowledge Organization in Systems Engineering
The concept of System Knowledge Repository (SKR) is born
(source: INCOSE –UK chapter)
SKR

System Knowledge Repository (SKR)
Allows representing, storing, managing and
retrieving
Relevant knowledge around the System
and its domain (including the SE Process)
Digital content (Assets) regarding a
particular System
The SKR is formed by
SKB – System Knowledge Base
SAS – System Assets Store

SKB
Supports the complete system knowledge-
base for the application of semantic services
around the system life cycle (Including SE).
SAS
Manages a formal representation of the
System Assets: Requirements, Models, etc.
Is the base for offering services around these
assets
Reuse
Traceability
MDE,TDD, etc.

System of Systems
Sub-System Knowledge Base (SSKB)

…

System of Systems

System Assets Store (SAS)
Assets (SAS)

(source: James Martin)
A reusable implementation

Controlled vocabulary: valid terms,
forbidden terms… Optionally can
include a Glossary (description for every
term).
Thesaurus:
Relationships between
terms: hierarchies,
associations, synonyms…
Light Ontology:
syntactic and Semantic
groupings for Terms and
Actions (verbs). Domain
terms and verbs.
Patterns and
Representation Schemas for
Identifying (patterns) and
representing (Schemas) the
semantics of knowledge in
digital artifacts.
System Knowledge Base: Ontology
What is an ontology for TRC?

Controlled Vocabulary
Needed for standardizing and normalizing the terminology used in the custom
application.The input information must/should match the controlled vocabulary.
Using a glossary with different categories of terms, the ontology may store:
Business related Terms : those terms central to the business area to be treated
General Language Terms:
Syntactically relevant phrases: Adverbs, Adjectives, etc.
Invalid terms: those terms that could be of no relevance.
Engine
based
vehicles
Vehicles
Emissions
control
Pollution
emissions
Legislation
Environment
al impact
evaluation
Noise
and
vibration
s
Air
conditioning
Air flow
Conduct
Diesel
engines
Gas Engines
Electric Engines
Engines
Hybrid engines
Pressure
loss
Vehicle
structure
Door
structure
Window
Security
Safety and
health
Hvac system
Doors

Controlled Vocabulary : Example for Requirements Authoring (RA)
UR044 :The Rad8 shall be able to identify hits at a minimum rate of 10 units per second
shall
identify
hit
unit
minimum
second
…..
The
to
at
Rad8

Thesaurus
A Thesaurus stores relational information regarding the terms in the glossary.
Used For:
Retrieval purposes
Representation normalization purposes
Suggestion purposes (Decision support)
“solution specific” purposes
Stakeholder
User
Administrator
Standard user
Customer
Administrator
Admin
Engine
based
vehicles
Vehicles
Emissions
control
Pollution
emissions
Legislation
Environmental
impact
evaluation
Noise and
vibrations
Air
conditioning
Air flow
Conduct
Diesel
engines
Gas Engines
Electric Engines
Engines
Hybrid engines
Pressure loss
Vehicle
structure
Door
structure
Window
Security
Safety and
health
Hvac system
Doors

Thesaurus : Example for RA
UR044 :The Rad8 shall be able to identify hits at a minimum rate of 10 units per second
Rad8
identify
second
…..
Rad8 PTT Radar Sonar=
Distinguish =
UR03442 :The Radar shall be able to distinguish hits at a minimum rate of 10 elements per s
s =

Light Ontology
Syntactic Information (Term Tag)
For NLP purposes
For specific Pattern Restrictions
Semantic Information
For Retrieval purposes
For specific Pattern Restrictions
Idiomatic Information
For NLP purposes
ArtifactType Information
For Retrieval Filtering purposes

VERBS
NOUNS
Syntactic Information : Application to Requirements
Authoring
UR044 :The Radar shall be able to detect hits at a minimum rate of 10 units per second
Doppler radar
identify
Radar Sonar
Detect
UR563 :The Doppler Radar shall be able to Identify hits at a minimum rate of 10 units per
second
PREPOSITIONS OFA

<DETECT>
Verb Semantic
<DETECTION DEVICE>
Term Semantic
Semantic Information : Application to Requirements
Authoring
UR044 :The Radar shall be able to detect hits at a minimum rate of 10 units per second
Doppler radar
identify
Radar Sonar
Detect Recognize
UR563 :The Doppler Radar shall be able to Identify hits at a minimum rate of 10 units per
second
DOMAIN TERMS
Doppler radar Radar
DOMAINVERBS
identify

Patterns
Sequential restrictions structure with place-holders for the specific terms
and values that constitute a particular knowledge statement, where the
restrictions can be grammatical, semantic, or even both, as well as other
patterns.
A pattern encapsulates the rules for writing and validating a knowledge
statement of a particular kind.

Patterns : Sequence of Restrictions (in place holders)
Restrictions:
Term
Syntax
Semantic
Syntax + Semantic
NL Text:
Term1 Term2 Term3 Term4 Term5 Term6
Restriction 1 Restriction 2 Restriction 3 Restriction 4 Restriction 5 Restriction 6

Patterns: Application to Requirements Authoring
UR044 :The Radar shall identify hits at a minimum rate of 10 units per second
Detection Pattern 1
The
<OBJECT
DETECTION>
Shall <DETECT> <ITEMS> <MINIMUM>At Rate of
<RATE
VALUE>
[NUMBER ]

Representation Schemas
Create a formal representation of the knowledge Statements based on the
Pattern information
<<Semantic of
Term2>>
Term2
Term1 Term3
<<My
Semantic>>
Term3 Term6
NL Text:
Term1 Term2 Term3 Term4 Term5 Term6
Restriction 1 Restriction 2 Restriction 3 Restriction 4 Restriction 5 Restriction 6

Representation Schemas : Application to Requirements
Authoring
<<Detect>>
Identify
Radar Hits
<<Minimum
Value>>
Hits 10
Units per
Second
UR044 :The Radar shall identify hits at a minimum rate of 10 units per second
The
<OBJECT
DETECTION>
Shall <DETECT> <ITEMS> <MINIMUM>At Rate of
<RATE
VALUE>
[NUMBER ]

Representation Schemas
UR044 : The Radar shall identify hits at a minimum rate of 10 units per second
UR852: Targets shall be detected by the Electromagnetic sensor at a frequency not lower
than 10 units per second
UR044
UR852
Synonyms
Electromagnetic sensor
Electromagnetic device
System
Lidar
…
Synonyms
Target
Echo
…
Semantic equivalences:
Identifies
Find
Distinguish
Discover
…
<<Detect>>
Radar Hits
10
Units per
Second
<<Minimum
Value>>
System
Knowledge
Repository

Applications of OBSE to Requirements Quality Mgmt.
Application 1
Use of Ontologies for CCC

Application 1 - Use of Ontologies for CCC metrics
Correctness
Consistency
Completeness
Several possible metrics
Consistency
(Redundant
requirements)
Consistency
(Inconsistent
units)
Completeness
(Missing
requirements)
Correctness
(Individual
requirement
metrics)
Completeness
(Missing links)

Correctness : Individual requirements metrics
 Size
 Readability
 Conditional vs. imperative sentences
 Active vs. passive voice
 Optional sentences
 Ambiguous sentences
 Subjective sentences
 Implicit sentences
 Abuse of connectors
 Negations
 Speculative sentences
 Use of false friends
 Design terms
 Flow terms
 Number of domain nouns and verbs
 Acronyms
 Hierarchical levels
 Volatility
 Number of dependences
 Is a Standard Requirement

Individual requirements metrics for correctness 1/3
 Size: expressed in paragraphs, chars, nouns or verbs. Long requirements will be difficult to
understand
 Readability: number of letters between punctuation marks and some other formulas
than indicate whether the requirement will be easy to read. Ease to read requirements
generates less problems all over the project
 Conditional sentences vs. imperative sentences: avoid “would” and use “Shall”,
“should” and “will” in the right way
 Active vs. passive voice: avoid using passive voice to increase the readability of the
requirement
 Optional sentences: ”maybe”… Optional requirements must be stated by an attribute,
never in the body of the requirement
 Ambiguous sentences: ”fast”,“user-friendly”… What do the analyst, the coder and the
customer understand by the same ambiguous sentence

 Subjective sentences: ”in my opinion”,“I think that”… Don’t show your ideas, but what the
system should do
 Implicit sentences: ”It must be provided by them”…Too many pronouns make your
requirements difficult to understand
 Abuse of connectors: “and”,“or”… Many times connectors reveal different needs enclosed
within the same requirement, loosing the atomic characteristic
 False friends: customized according to “native language” of your project
 Negations: “no”,“never”…Two or more negations in the same sentence make it difficult to
understand
 Speculative sentences: ”usually”,“almost”,“always”… Make the requirement imprecise
 Design terms: ”loop”,“hash”… Remember: avoid How, concentrate inWhat
 Flow terms: ”while”,“if”,“else”… Remember: avoid How, concentrate inWhat

 Number of domain nouns and verbs: domain terms and verbs should be involved into
the requirement specification, nevertheless, too many different terms in the same
requirement many times means multiple needs
 Acronyms: avoid those that don’t belong to the domain representation
 Hierarchical levels: don’t complicate your specification with too many indentation
levels
 Volatility: if a requirement suffers many changes, you must be very careful with it
 Number of dependences: the same if your requirement is the source of too many
dependences
 Standard Requirement: The requirement can be matched with one or many of the
requirement templates defined by the organization.

Correctness
Negations
Conditional Sentences
DesignTerms
Connectors
etc.
Controlled
Vocabulary
Thesaurus
Light
Ontology
Patterns and
Representation
Schemas
Acronyms
Standard Requirement

Metrics for consistency
 Redundant requirements: Several requirements expressing the same need at
the same level of abstraction.
 Inconsistent units: Different requirements in the same module/block/project
uses different metric units.
 Value restrictions: Different requirements present value restrictions that are
not compatible.

Consistency
Redundant requirements
Controlled
Vocabulary
Thesaurus
Light
Ontology
Patterns and
Representation
Schemas
Inconsistent Units
Value restrictions

Metrics for completeness
 Missing requirements: Lacks the existence of requirements expressing the
same need at the different level of abstraction in different modules/blocks of the
same project.
 Missing Links Lacks the existence of links between requirements expressing
the same need at the different level of abstraction in different modules/blocks of
the same project.

Completeness
Missing Requirements
Controlled
Vocabulary
Thesaurus
Light
Ontology
Patterns and
Representation
Schemas
Missing Links

Completeness

Applications of OBSE to Requirements Quality
Application 2
Smart Requirements Authoring

Application 2 – Smart Requirements Authoring
Requirements Authoring :
V&V&V on the fly
A well written set of requirements would reduce the reviewing cost.
If requirements arrive to the Quality Management group with low quality,
the quality assessments becomes an expensive task
Activities assessing requirements quality during authoring time
will reduce quality management groups workload
will reduce even more the effort for reviewing.

V&V&V on the fly

V&V&V on the fly
Requirement
Validated
VerifiedVerified
Organization System
Stakeholder
Match the Requirements against the Organization’s quality standards
(boilerplates, terminology, semantics, etc.)

Requirements Authoring tools
Properties of a Requirements Authoring tool
It must calculate the same metrics that the Requirements Quality Analyzer but
on the fly
The author must get information about the quality of the written
requirements before they are saved on the Requirements Management
Tool
It must be integrated with the Requirements ManagementTool
It must be simple and with a non aggressive GUI.
It must advice, as much as possible about the CCC metrics
Correctness
Completeness
Consistency

Demo Video

Requirements Authoring Tool – RAT V4.0 Simple

Requirements Authoring Tool – RAT V4 Complete

Conclusions
The challenges in SE are growing
Knowledge Management is a present/future key factor in SE for helping to
handle with growing complexity
Ontologies are promising enablers
The application of Ontologies in Requirements Quality Management is a
successful application at present time
Pilot projects show viability of the approach.

http://www.reusecompany.com
contact@reusecompany.com
Margarita Salas, 16 2nd Floor
Innovation Center
LEGATECTechnology Park
28919 Leganés – Madrid
SPAIN – EU
Tel: (+34) 91 146 00 30
Fax: (+34) 91 680 98 26

OBSE - Ontology Based System Engineering

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to OBSE - Ontology Based System Engineering

Similar to OBSE - Ontology Based System Engineering (20)

More from The REUSE Company

More from The REUSE Company (13)

Recently uploaded

Recently uploaded (20)

OBSE - Ontology Based System Engineering