Systems Engineering Requirements: A Guided Example
of an Applied Knowledge System
Anabel Fraga and Juan Llorens
Carlos III of Madrid University, Madrid, Spain
Abstract. Knowledge is centric to systems engineering, the knowledge man-
agement process must take into account that a System Knowledge Repository
(SKR) exists as a key element for either quality improvement, traceability sup-
port and, in summary, reuse purposes. Requirements engineering in the Sys-
tems Engineering process is enhanced by using knowledge systems and quality
of requirements enriched as well. The more correct, complete and consistent a
requirement is, the best performance it will have and knowledge systems enable
a more exhaustive and fast quality process. A knowledge management process
is proposed and it is guided by a requirements domain based example.
Keywords. Requirements Engineering, Ontologies, Knowledge, System engi-
neering, Reuse.
1 Introduction
The application of ontology engineering in systems engineering seems to be a very
promising trend [12], [4]. We call it system verification based on Knowledge Man-
agement, and it deals with assisting System Engineers to get a complete and con-
sistent set of requirements (e.g. compliance to regulation, business rules, non-
redundancy of requirements…) by using Ontologies, which represent the domains of
knowledge of an organization. The combination of Requirements Engineering with
Knowledge Management, throughout Information Retrieval from existing sources,
allows the verification process to measure quality of a set of requirements by tracea-
bility, consistency/redundancy, completeness and noise. Information retrieval ena-
bles also to verify the completeness of the ontology using a PDCA (Plan-Do-Check-
Act) cycle of improvement. Requirements engineering is the first step and by tracea-
bility and Ontology based systems, similar assets of any phase of the development
process used in analogous projects could be reused and adapted to a new challenge.
For instance, by using a semantic approach, a requirement can be translated into a
graph by means of NLP (Natural Language Processing) techniques.
In order to build a knowledge repository for managing requirements quality, the
first activity must be to clearly define the typology of requirements that are going to
be covered by the knowledge system, because this typology will affect the require-
ments structure and vocabulary. For example, an organization would be interested in
managing the quality of “performance requirements”. Even if it seems to be simple,
the selection of the kind of requirements to formalize in a knowledge repository is
Fraga A. and Llorens J..
Systems Engineering Requirements: A Guided Example of an Applied Knowledge System.
DOI: 10.5220/0005177700190030
In Proceedings of the 5th International Workshop on Software Knowledge (SKY-2014), pages 19-30
ISBN: 978-989-758-051-2
Copyright
c
2014 SCITEPRESS (Science and Technology Publications, Lda.)
not trivial. “In order to define what I want, I usually need to know what I do not
want”. And this is a real problem. Because in many cases “performance require-
ments” will NOT be considered by you as “functional requirements”, but in other
cases they certainly will. Figure 1 shows a requirement types taxonomy.
Fig. 1. Taxonomy of requirements types.
A requirement is an identifiable element of a function specification that can be vali-
dated, and against which an implementation can be verified. [1] [7] [6] [11] [5] [3] [2]
Requirements Development encompasses all of the activities involved in eliciting,
analyzing, specifying and validating the requirements.
Requirements Management encompasses the activities involved in requesting
changes to the requirements, performing impact analysis for the requested changes,
approving or disapproving those changes, and implementing the approved changes.
Furthermore, includes the activities used for ensuring that work products and project
plans are kept consistent and tracking the status of the requirements as one progresses
through the software development process.
There are some rules that establish how the requirements must be written and which
mistakes must be avoided. The INCOSE (International Council on Systems Engineer-
ing) rule states that the requirements must be clear and concise, complete, consistent,
verifiable, affordable, achievable, necessary, bounded, traceable with independent
implementation. [8] Any mistake in the requirements definition phase is distributed
downwards until low level requirements being almost impossible to fix. Thereby,
those mistakes must be caught in the early development process.
2 Knowledge Management Process
Stage 0. Inmature Situation
An organization is in an Immature situation for the knowledge management pro-
cess when there is no conscious understanding of the need of managing assets for
20
their (re)-use internally.
Stage 1: Managing SAS
This stage is gathered as soon as the organization has implemented whatever activity
for supporting an assets store. Usually, this store is based on a defined model for an
assets repository (the most common is the OMG [13]).
Stage 2: Managing Terminology
This stage is reached when the organization is managing the terminology that affects
the system of interest. The existence of a controlled vocabulary of terms, as concepts,
allows the quality management process to produce relevant metrics about the work-
products, and therefore it is a key stage to provide qualified assets as well.
In this stage we will start with our guided example, imagine a system “Car”, with
components like “Brakes”, “Pedals”, and also actions even when the pedals are
“pressed”, and also additional variables as “velocity” and “time of speed”.
Here the vocabulary and thesaurus must be built. For instance:
The project breakdown structure (PBS) also contains useful information:
Car = System
Brake = Brake System
Pedal of the brake
Pedal States: Pressed, Released
Knowledge about the physical world also helps to understand the requirement:
Measurement unit equivalence
Speed -------------------------------------- V
Acceleration --------------------------------- A = V’
| Antinomy
|___________________>Deceleration
Stage 3: Managing the System Conceptual Model (SCM)
When an organization supports a persistent representation of a SCM, it becomes an
asset ready to be reused. The existence of a SCM allows the quality management
process to produce advanced metrics about the work-products. In organizations that
only want to develop the Knowledge Management Process for Knowledge Reuse,
this stage represents the possibility to reuse “ground truth” knowledge at the organi-
zation level. Those organizations that do not want to develop a SCM can have a light
stage, with almost no effort.
In this example the organization manages assets for indexing and retrieval. In this
stage the semantic grouping of concepts must be managed, at conceptual level it is
not showed but semantics will be implemented in a tool, as for instance Protégé [10],
Knowledge Manager [9], and so on.
21
Stage 4: Managing Patterns
Patterns are developed with the intention to be matched to Systems Engineering
work-products content. When an organization owns a set of patterns, it becomes pos-
sible to identify relevant structures inside the produced content. By using patterns
matching, specialized software can identify the patterns inside artifacts and be able to
assign them the patterns as a means to classify them. The existence of patterns allows
the quality management process to identify the typology of the work-products. On the
other side, the Knowledge Management process needs patterns as the first stage to
properly formalize them.
In the case of a requirement like: “Whenever the pedal of the brake is pressed, the
car shall decelerate immediately”
A quick first syntactical analysis will present the following structures:
Whenever
The
Pedal of the brake
Is pressed
The
Car
Will
Decelerate
Immediately
Two syntactic structures have to be considered here: The compound noun “pedal of
the brake” and the compound verb “is pressed”. The joining of those words as a sin-
gle compound phrase is performed by the Tokenization stage of the process.
We´ll not produce patterns at syntactical level because we consider that “Pedal of the
brake” is, in itself, a term of the domain with full meaning. This means that “Pedal of
the brake” must be included in the ontology. The structure “is pressed” will be split in
the two terms that form it: the verb “to be” and the verb “to press” in participle.
The patterns structure looks like:
Fig. 2. Pattern structure for the guided example.
22
Stage 5: Managing Formalization
In stage 4 the organization owns an ontology with formalization capabilities for dif-
ferent work-product types. The formalization information, today, is formed by rules
for producing formal representations of work-products.
The existence of Formalization information allows the quality management process to
produce advanced metrics about the work-products.
Due to the existence of formalization capabilities, the supported operations in the
previous stage are improved in the following way:
Artifact retrieve
The capability of the repository to formalize artifacts allows producing smart re-
trieval algorithms for semantic search, improving precision.
Artifact traceability
Due to the formalization capability, automatic trace policies based on similar con-
tent can be produced.
The following formalization will be used for the example we follow in this paper:
Fig. 3. Formalization of the requirement.
As it can be seen in the previous diagram, the trigger pattern produces by itself a
graph:
Fig. 4. Graph of the trigger.
23
The complete representation will be:
Fig. 5. Example of formalization.
But, a problem arises when trying to formalize the graphs out of the other patterns:
the graph we want to produce is formed by elements coming from different patterns
(reaction and time constraint):
Fig. 6. Example of formalization #2.
This means that it is not possible to formalize the graph only at the Reaction pattern,
and also not possible to formalize it at the time constraint pattern.
There are two solutions to this problem:
Unify the reaction pattern to include a section for the time constraint.
Create the graph at the next level, where both patterns exist as sub-patterns.
In our case, we´ll use the second solution, so the formalization will be produced at
the next level of patterns.
24
This formalization process is, of course, very human dependent, and we must not be
afraid of that. The result of this process must be the way the organization understands
the requirement semantics. Just by defining a way, good benefits of it can be gathered
(sharing same understanding, promoting the view to the supply chain etc etc.)
For example, other Systems Engineering group could see the studied requirement as a
state machine transition, and the modeling could be a different one.
Fig. 7. Pattern structure.
Stage 6: Managing the System Knowledge Repositiry (SKR)
In stage 5 the organization has included inference information to the ontology, com-
pleting the System Knowledge Base (SKB) and forming a complete System
Knowledge Repository (SKR).
Inference information is necessary, as well, for the quality management process, in
order to produce consistency metrics.
Usually, the inference rules for decision making purposes are based on the existence
of a full developed SCM. Therefore, in some cases, the SCM is fully developed in
this stage.
Due to the existence of inference capabilities, the supported operations in the previ-
ous stage are improved in the following way:
• Artifact transformation
The existence of inference information allows generating new knowledge based on
previous artifacts. For example: a rule could allow a user to state a complex query
using UML, asking the repository to create new UML models with the information in
the similar artifacts that is NOT existing in the query, and being notified of them by
producing new artifacts.
• Artifact traceability
Due to the inference capability, automatic trace policies based on transformations
can be produced.
Once a terminology, a thesaurus, patterns and its formalization has been done, if a
requirement instance of a type matching is needed, as for instance: “If the car is mov-
ing, whenever the pedal of the brake is pressed, the car will decelerate immediately”.
The SCM plays its role and indexing/retrieval systems are involved in the process.
The knowledge system is completed and implemented in a Knowledge System as
Knowledge Manager [9] that fully support this kind of process and even patterns are
available for this kind of requirements.
25
3 How to Manage Terminology: a Basic Step for the Process
As stated for Stage 2, the existence of a controlled vocabulary of terms, as concepts,
allows the quality management process to produce relevant metrics about the work-
products, and therefore it is a key stage to provide qualified assets as well. The se-
quence diagram explaining the process is shown in Figure 8. First of all, it is im-
portant to notice that diverse environments (areas) are suggested to be active in any
new implantation of a Knowledge Management Process: Production, Pre-production,
and Evolution (New Version of the Ontology). In the Evolution area, the ontology is
evolved based on the domain artifacts once it is ready then it is set as active and rep-
licated in Pre-Production and Production areas. In the Pre-Production area indexing
of new artifacts in an incremental mode is done based on the ontology active at that
moment that maybe is not the one active in the Evolution area. In the Production area
the retrieval process is done based on the indexing available and the ontology active
at that point. Figure 8 shows a piece of the process between Production and Evolu-
tion areas focus on the terminology point of view.
Fig. 8. Terminology process sequence diagram.
A Terminology List is needed for standardizing and normalizing the terminology
used in the custom application. The input information must/should match the con-
trolled vocabulary. Using a glossary with different categories of terms, the ontology
may store:
Business related Terms: those terms central to the business area(domain) to be treated.
26
General Language Terms: those terms related to the basic language used in the
ontology (i.e. English, Spanish, German, and so on).
Syntactically relevant phrases: those are general language terms related to the
General Language Terms: Adverbs, Adjectives, etc.
Stop Terms: those terms that could be of no relevance.
Gathering Vocabulary: How It Works
The terminology of the domain must be extracted of the artifacts in the domain. For
that reason, a sequence of steps must be completed, as shown in Figure 9:
Tokenization
Normalization
Disambiguation
Phrase recognition
Fig. 9. Steps for gathering terminology.
An example of the steps to be completed for gathering the terminology of the domain
is as follows:
All Radars shan’t identify the following targeting enemy objectives:
27
The steps of tokenizing, normalizing, disambiguation and phrase recognition are
shown above. As complementary, a state machine diagram is included as Figure 10 as
an illustrative sequence of the whole process.
Fig. 10. State diagram showing the gathering terminology steps.
Ontologies Maintenance: Effort / ROI Perspective
The perception that building ontologies to improve Systems Engineering could imply
a project with negative ROI is certainly real within organizations. The REUSE Com-
pany has produced a methodology that has as main goal to discourage this thinking.
The fundamental aspects of this approach are:
Define a SIMPLE schema/ Meta-model for the Ontology, avoiding complex
structure
Create Semi-automatic methods to produce the ontology layers at low cost
To k e n i z a t i o n
Normalization
Disambiguation
Phrase
Identification
[All][Radars][shall][not][identify][the]
[following][targeting][enemy][objectives][:]
[All][Radar][shall][not][identify][the]
[following/follow][targeting/Target][enemy]
[objective][:]
[All][Radar][shall][not][identify][the]
[following][Target][enemy][objective][:]
[All][Radar][shall][not][identify][the]
[following][Target][enemyobjective][:]
28
Define clear applications of the ontology inside the SE lifecycle, like, for in-
stance, the requirements quality control
Define a PDCA cycle to reduce the cost of maintenance
Finally, the experience has shown that, once the ontology is specialized to particu-
lar usages, the maintenance cost decreases very quickly once a determined level of
maturity is gathered.
Fig. 11. ROI graphical representation.
These arguments allow producing positive ROI easily.
4 Conclusion
Once the Knowledge Management Process was introduced and a guided example
shown, the next step is the full definition of the example in a tool supporting all the
Lifecycle of a requirement coexisting in a Knowledge System Repository. It is in
progress and partially implemented at this point. The whole tool is in its process to be
improved and completed for supporting the whole Knowledge Management Process
for any project, company or organization.
The requirements in any project are one of the most important assets, if not the
most. A bad group of requirements might have terrible implications in a developed
system. For instance a requirement detailed in various parts of the requirement list
using different measurement units might cause an accident or a failure during opera-
tion of any system.
Classical sequential review process of requirements is costly in terms of time con-
suming. Then support of tools for lexical, syntactic analysis enables to correct bad
requirements writing before business of project reviews.
One of the next challenges in the Industry is to reach an ontology-assisted system
engineering process to write SMART requirements at a first shot.
The use of ontologies and patterns is a promise of doing better requirements engi-
neering and knowledge reuse in any system engineering project.
29
Acknowledgements
Authors thank Manuela Berg and Thomas Peikenkamp, both from OFFIS, for the
requirement textual example provided for this guided definition of the process.
The research leading to these results has received funding from the european union’s
seventh framework program (fp7/2007-2013) for crystal – critical system engineering
acceleration joint undertaking under grant agreement n° 332830 and from specific
national programs and / or funding authorities.
References
1. Eric Braude. Software Engineering. An Object-Oriented Perspective. John Wiley & Sons,
2001.
2. Genova, G. Fuentes, J. Llorens, J. Hurtado, O. Moreno, V. A framework to measure and
improve the quality of textual requirements, Requirements Engineering, Springer, Url:
http://dx.doi.org/10.1007/s00766-011-0134-z, Doi: 10.1007/s00766-011-0134-z
3. Guide for Writing Requirements, INCOSE Product INCOSE-TP-2010-006-01, V.1, April
2012
4. H. Chale et al., Reducing the Gap between Formal and Informal Worlds in Automotive
Safety-Critical Systems, INCOSE Symposium 2011, Denver.
5. Ian F. Alexander & Richard Stevens. Writing better requirements. Addison-Wesley, 2002.
6. Ian Sommerville & Pete Sawyer. Requirements Engineering: A Good Practice Guide. John
Wiley & Sons. 1997.
7. Ian Sommerville. Software Engineering. Pearson-Addison Wesley, 2005.
8. INCOSE, Systems Engineering Handbook. http://www.incose.org/ProductsPubs/
products/sehandbook.aspx (last visited 11/13/2013)
9. OBSE Fundamentals, The Reuse Company, Juan Llorens (UC3M) - José Fuentes (TRC).
http://www.reusecompany.com (last visited 11/13/2013)
10. Protégé. Stanford University Development. http://protege.stanford.edu (last visited
11/15/2013)
11. Roger Pressman. Software Engineering: a practical guide, 6ª ed. McGraw-Hill.
12. The Reuse Company (TRC). http://www.reusecompany.com (last visited 11/13/2013)
13. The Reusable Assets (RAS) - OMG. http://www.omg.org/spec/RAS/2.2 (last visited
01/07/2014)
30