Upload
the-reuse-company
View
395
Download
1
Embed Size (px)
DESCRIPTION
Ontologies can enhance the quality of the System Engineering process. This presentation shows how to apply ontologies to this process and, more specifically, to the Requirements Engineering process.
Citation preview
Ontology Based Systems Engineering
Nordic Systems Engineering Tour – April, 2013
www.reusecompany.com
2 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Juan Llorens
CTO in The Reuse Company
Professor at Carlos III University
Technical Director of INCOSE’s Spanish Chapter
3 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Fundamentals of
Ontology Based Systems Engineering (OBSE)
4 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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
5 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Need of knowledge for better Systems Engineering
The “smarter” we want systems engineering to be, the more dependent on
“semantic” knowledge shall it be. Challenges for Requirements Quality Mgmt.
(source: Gauthier Fanmuy - the RAMP project: - AFIS)
6 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Need of knowledge for better Systems Engineering
The “smarter” we want systems engineering to be, the more dependent on
“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
7 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Knowledge Organization in Systems Engineering
The concept of System Knowledge Repository (SKR) is born
(source: INCOSE –UK chapter)
SKR
8 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Knowledge Organization in Systems Engineering
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
9 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Knowledge Organization in Systems Engineering
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.
10 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Knowledge Organization in Systems Engineering
System of Systems
Sub-System Knowledge Base (SSKB)
11 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Knowledge Organization in Systems Engineering
Sub-System Knowledge Base (SSKB)
…
12 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Knowledge Organization in Systems Engineering
System of Systems
Sub-System Knowledge Base (SSKB)
13 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Knowledge Organization in Systems Engineering
System Assets Store (SAS)
Assets (SAS)
14 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
(source: James Martin)
Knowledge Organization in Systems Engineering
A reusable implementation
15 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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?
16 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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
17 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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
18 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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
19 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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 =
20 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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
Artifact Type Information
For Retrieval Filtering purposes
21 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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 OF A
22 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
<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
DOMAIN VERBS
identify
23 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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.
24 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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
25 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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 ]
26 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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
27 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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 ]
28 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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
29 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Applications of OBSE to Requirements Quality Mgmt.
Application 1
Use of Ontologies for CCC
30 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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)
31 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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
32 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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
33 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Individual requirements metrics for correctness 2/3
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 in What
Flow terms: ”while”, “if”, “else”… Remember: avoid How, concentrate in What
34 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Individual requirements metrics for correctness 3/3
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.
35 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Correctness
Negations
Conditional Sentences
Design Terms
Connectors
etc.
Controlled Vocabulary
Thesaurus
Light Ontology
Patterns and Representation Schemas
Acronyms
Standard Requirement
36 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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.
37 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Consistency
Redundant requirements
Controlled Vocabulary
Thesaurus
Light Ontology
Patterns and Representation Schemas
Inconsistent Units
Value restrictions
38 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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.
39 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Completeness
Missing Requirements
Controlled Vocabulary
Thesaurus
Light Ontology
Patterns and Representation Schemas
Missing Links
40 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Completeness
41 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Applications of OBSE to Requirements Quality
Application 2
Smart Requirements Authoring
42 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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.
43 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
V&V&V on the fly
44 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
V&V&V on the fly
Requirement
Validated
Verified
Verified
Organization
System
Stakeholder
Match the Requirements against the Organization’s quality standards
(boilerplates, terminology, semantics, etc.)
45 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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 Management Tool
It must be simple and with a non aggressive GUI.
It must advice, as much as possible about the CCC metrics
Correctness
Completeness
Consistency
47 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Demo Video
49 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Requirements Authoring Tool – RAT V4.0 Simple
50 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
Requirements Authoring Tool – RAT V4 Complete
52 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour
Ontology Based Systems Engineering
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
Margarita Salas, 16 2nd Floor
Innovation Center
LEGATEC Technology Park
28919 Leganés – Madrid
SPAIN – EU
Tel: (+34) 91 146 00 30
Fax: (+34) 91 680 98 26