Using ontologies in requirements management: A meta-study
An ontology is a formally structured model in the field of knowledge management. Ontologies can also help us in requirements management. But how exactly? Diego Dermeval and his colleagues investigated this a few years ago. They took a close look at 67 publications. Here are the most interesting results.
What is an ontology in the context of requirements?
I have already explained what an ontology is in another article described. Specifically, an ontology is a formal description of the concepts we use and the relationships between them.
In requirements management, we need to have a clear understanding of the terminology. Not only that: although there is no one "right" ontology for a project, the structure of the ontology has a direct influence on how effectively we can carry out requirements management activities.
To assess this, we need to look at the different activities. The authors of the paper examine activities such as elicitation, requirements analysis, domain and system modeling, testing and reuse.
The paper
The 33-page paper published in 2016 has the Title Applications of ontologies in requirements engineering: a systematic review of the literature. The authors examined a total of 67 studies.
With such papers, the question often arises as to how relevant the results are for industry. In fact, the majority of the papers examined are academic. After all, 15 of the papers (22%) had an industrial context.
As usual in a meta-study of this kind, the authors examine a number of specific questions about ontologies in requirements management. Here are the most interesting results:
Ontologies... for what purpose at all?
Ontologies can be used in various areas of requirements management. The authors have sorted these according to purpose.
Six studies dealt with a generic Ontology for requirements management. The ontology therefore deals with the concepts that can later be used to describe the processes.
Five studies, on the other hand, dealt with Ontologies of the problem space (Domain Knowledge Ontology). Such an ontology ensures that stakeholders can make precise statements about aspects of the problem to be solved - this is essential in requirements management.
Four studies deal with "Foundational Ontologies", which serve as the basis for customized ontologies. Of particular interest to us systems engineers is the Unified Foundational Ontology (UFO)for which there is also the UML profile OntoUML gives.
The remaining ten ontologies cannot be grouped into larger categories and are specialized for security, goals, design, etc.
Phases of requirements management processes and the approaches used
Ontologies are used by far the most in the specification phase (84%), followed by analysis (58%), management (36%) and elicitation (25%). The proportion in the validation phase is rather low at 6%.
The researchers also dealt with "approaches", referred to as "requirements modeling styles". This refers to textual notation, UML, BPML, etc. More interesting than the numbers themselves is the relationship between the approaches and the phases:
It is not surprising that text and UML dominate. The comparatively high proportion of more academic approaches is certainly due to the fact that almost 80% of the papers examined were not conducted in an industrial context.
Problems that have been proven to be mitigated by ontologies
Question RQ4 dealt with specific advantages of using ontologies. The authors differentiated between whether these advantages were empirically proven or not.
The lion's share of the papers focuses on the following three topics:
- Reduction of ambiguity, inconsistencies and incompleteness
- Support requirements management and maintenance
- Presentation of the problem domain to support the survey activities
The authors cite empirical evidence for all three topics. These are also the issues that we as systems engineers have to contend with due to the increasing complexity of our systems.
Further topics
The extensive paper deals with other topics that I have not explicitly addressed here, such as recycling, V&V activities, etc. One of the reasons for this is that the authors found comparatively little information on these topics. For interested readers who would like to know more, I recommend reading the paper.
Benefits in practice
This paper is a meta-study. I recommend that teams who want to use ontologies start with a problem or use case. Does the challenge lie in the processes? Then it might make sense to Ontologies for requirements management to take a closer look.
However, if there are problems with the specification, then Ontologies for the problem space perhaps more helpful.
The problem can then possibly be further exacerbated, such as problems with the elicitation of requirements. The scope could also play a role (software only, security aspects, etc.). Equipped in this way, we can then find the studies that help us with these problems.
Conclusion
Ontologies are not yet widely used in requirements management, but they are a powerful tool for mastering the complexity of product development in the long term. Introducing ontologies in the right place today can lay the foundation for long-term success in the team.
