Requirements specification and ontology building
Author(s): Julia Szota-Pachowicz
Full text: submitted version
Abstract: The connection point between requirements specification and ontology is an explicit formal specification. Sharing knowledge is crucial for these both activities. Building an ontology in parallel with requirements specification activity leads to produce better quality specification, helps to understand the domain knowledge and to find a consensus on the content between engineers and end users. The purpose of requirements specification is to clearly define the functionality of the application in order to design it properly and implement it. In this case, the ontology describes knowledge that the requirements specification provides. The usage of ontologies to the problem of describing the functionality of the system can be used in further development and integration with other applications.
Keywords: ontology; requirements specification; UML
Review 1 (by Eva Blomqvist)
Unfortunately I disagree with this paper already in its first sentence. Disagreement is of course not a reason for rejecting a paper, however, the author does not follow up the claims in the paper with proper evidence, hence, my suggestion for rejecting it. The paper topic is about integrating ontology engineering into the software requirements engineering process, which is actually a very important topic, that is clearly worthy of exploration. I agree that these processes share many tasks and resources, and when building an ontology targeted to be used in a software system, the processes can probably greatly benefit from being done in parallell (although this is not shown in the paper either, it is just my opinion). I would really like to see more approaches that integrate ontology engineering into software engineering processes in the future, so the authors is clearly on the right track here! However, to claim that the process of requirement specification can directly be used to also specify an ontology, is to take things too far, in my opinion. I am not ready to accept that hypothesis without much more evidence than this paper provides. Starting from the very first sentence of the abstract, the author there claims that the connection point between the activities is an "explicit formal specification", but this is where I start to disagree. Does the requirement specification have to have a formal representation, i.e. machine readable with well-defined semantics? Of course, this could be the case, but I would say that most requirements are specified visually in diagrams (without clear formal semantics) or in natural language text, rather than as an explicit formal specification. Overall, I have two main issues with this paper: 1) What is actually the purpose of building the ontology? Is the ontology to be used in the software being built? Then it should have a set of other requirements as well, such as what querying and reasoning tasks it should support, and not only be a representation of terms found in the requirements elicitation. Or is the ontology built simply as a formal representation of the software requirements? Then why is it needed at all? What would you do with that ontology after it has been built? There are already formal specification languages for building software, why not use those instead? 2) The paper completely lacks an evaluation of the approach. A kind of "toy example" use case is presented, however, it is not enough, neither to show exactly how things would work in practice, technically, nor to establish the usefulness of the approach. Based on these issues, I do not see that the paper fulfils the requirements in the call for papers, i.e., neither showing clear impact of semantic technologies, showing the extent to which real-life problems are addressed, nor being properly evaluated to expose pros and cons of the approach. Apart from that, the paper is also not very well written, it contains lots of spelling and grammar errors, which makes it hard to read, and lacks a lot of technical details that might have potentially made it more clear what the approach is actually trying to achieve.
Review 2 (by anonymous reviewer)
This 9-page paper reports an approach describing how three requirements activities (elicitation, analysis and specification) and ontology building activities can be joined and what benefits can be achieved by linking these two activities. We have based the evaluation of the paper on the five criteria provided by the In-Use track chairs: 1. Measurable impact of semantic technologies: The impact of the approach was not measured, and no measures were proposed. 2. Extent to which the In-use paper addresses real-life problems: If the approach deals with a potential real-life problem (requirements engineering), it doesn’t address it really. The approach has not been faced with real cases, and not applied by users other than the authors (see below). 3. Novelty of the techniques applied in practice: The claimed novelty of the approach is that it combines requirements engineering (RE) activities with ontology building processes (as compared with existing approaches in which ontologies are used to support one or more requirements engineering activities). The difference between RE-Ontology combination and ontology-supported RE is not sufficiently explained. 4. Inclusion of an evaluation of the technology: The approach was not evaluated at all. It was only applied by the authors for explanation purposes, and only one time. The authors merely describe how they applied their approach. 5. Reflection on the pros and cons of the approach: The authors do not reflect on the pros and cons of the approach.
Review 3 (by anonymous reviewer)
The author presents intriguing points about parallels between domain ontology processes and application ontology processes. I think this would start a welcome conversation for an ESWC audience. This paper presents the application of ontologies toward requirements engineering -- specifically linking requirements specifications with the ontology construction process. It presents an intriguing argument for the benefits of bringing together domain knowledge expertise and engineering expertise (i.e. domain ontology and application ontology). The paper attempts to showcase the benefits of joining together requirement specification process and the ontology building. The author does a great job of outlining the primary activities in requirements engineering. They are elicitation, analysis, specification, validation, and management. They also argue that like an ontology, they should be complete and unambiguous. They make a strong case when they reiterate the point that OWL, with its formal semantics, can help identify overlapping and incompatible requirements that stakeholders may bring to an initiative. But the end result is an ontology that can be treated as a reference for the system requirements. Another strong point is in ssection 2.2 where the parallels of domain ontology and application ontology construction. Specifically: "preparation, anchoring, iterative improvement, and application". One part of the section that is left open and could have been where it is states that the anchor ontology is iterated on and improved until it meets all evaluating standards. Would be helpful to know if there is specific guidance on how this can be measured. In terms of the application ontology, the author describes the preparation phase and then moves on to building, where it says engineers discuss the meaning of each term and define it explicitly so that it is unambiguous for the system. This makes sense for the application ontology, but hardly seems scalable for large domain specific ontologies that are often constructed through automation and semi-automatic means. This is by no means a criticism of the process, but merely pointing out that this is one time where the two types of ontology processes may deviate. Section 4 describes the application process as applied to a system that allows students to enroll in courses. Based on the description, it may not be a huge ontology, which raises questions about how well this would actually scale.
Review 4 (by Monika Solanki)
In this paper, the author puts forward the thesis that the process of requirements specification for an application in a specific domain must go hand-in-hand with building an ontology that conceptualises the entities used in the requirements specification. An approach is presented that implements this thesis. The paper in general was very hard to read and comprehend. The literature review that has direct relevance to the proposed approach, has been confined to three lines of text in the paper. There is no rationale or justification on why the proposed approach was better than some of the existing ones that the author has referenced. The notion of an "anchoring ontology" is never explained. The difference between the first part of the process till the building of the anchoring ontology and the processes after that is not very clear. It appears to be an iterative process. Was this approach taking into account the agile methodology of system development? If not, why was this not considered? The example presented is a toy example and does not in any way reflect the real complexities that arise when systems are being developed collaboratively in large teams, where there could be no agreement on terms to eb used in the vocabularies. The fact that there is no evaluation and real life implementation of the proposed approach actual renders this paper out-of-scope of the track.
Review 5 (by Anna Tordai)
This is a metareview for the paper that summarizes the opinions of the individual reviewers. The reviewers appreciate the idea described in the paper that requirements engineering should go hand in hand with ontology creation. They point out that there is a lack of evaluation and measureable impact of the work. Finally, the reviewers note some problems with the presentation. Laura Hollink & Anna Tordai