Reusability of Requirements Ontologies By Rania Alghamdi
Outline Introduction Requirements Reuse Requirements ontologies Criteria of reusable requirements Examples of reusable ontologies Discussion and conclusion 2
Introduction Requirements Engineering (RE) consists of different activities [8]. Elicitation Analysis Documentation Validation Understanding the application domain. Dealing with requirements classification, modeling, and resolving conflicts. Aiming to produce requirements document (specification). Checking the final draft of a requirements document. The main goal of RE is to translate the needs of the stakeholders accurately to produce concise requirements specification. That takes a considerable time and effort. 3
Requirements Reuse As a result Requirements Reuse became necessary [2-4] oto decrease cost and time-to-market. oto benefit from the other existing high-quality requirements. Goldin and Berry [3] found: oreusing is difficult since it depends on choosing the correct components to reuse. othose components should be initially written to be reusable. oworking on requirements reuse is worth it and pays off. 4
Requirements Reuse According to Chernak s global online IT survey [4] Did you reuse requirements on your latest projects? No 41% Yes 59% What are the obstacles for adopting requirements reuse? 5%other Reuse is not supported 25% Incomplete 12% Reuse is not important 18% Outdated 19% Unstructured 21% 5
Requirements Reuse Approaches applied requirements reuse successfully Software Product Line (SPL) Software Requirements Catalog (SRC) Requirements ontologies It depends on exploiting the commonalities and the variations of all products in the line [5]. It focuses on developing a family of products [3]. It is conformed to large-sized software projects [2]. A set of related and sorted requirements. Requirements are classified based on their functions and priorities. More suitable to be applied in small-sized projects [2]. It is used to make the knowledge more sharable and reusable. It is used for large to small scale software project. 6
Requirements ontologies The concept of ontology is used to reduce the negative effects of RE challenges Some RE challenges Benefits of requirements ontology Stakeholders may give incomplete requirements. Stakeholders may provide redundant requirements with different vocabularies (ambiguity). Requirements change continuously. Using requirements ontology for specific domain help to capture the missing requirements such as the non-functional requirements [14]. Ontology is used to restrict vocabulary interpretations and the semantic relations between different entities [8]. The explicit relations between entities in the ontology help to trace any changes [8]. 7
Requirements ontologies According to the systematic review of Dermeval et. al [1] oontologies have been used to accomplish different RE activities. othey found empirical evidences of their advantages. o34% of the studies reused existing ontologies in their contributions to achieve various purposes. othey did not study the reusability criteria of those reused ontologies and they mentioned this part briefly. 8
Requirements ontologies Different studies reused ontologies for different purposes [1] : osome studies reused: Generic requirements engineering ontologies Domain knowledge ontologies Security ontologies Goal-oriented requirements engineering (GORE) ontology Business ontology Scenario-extended problem ontology Requirements ontologies are generally not widely reused. Blomqvist et. al related that to the poorly designed and documented ontologies [6]. 9
Criteria of reusable requirements 4. Being unambiguous 1. using well-known standards 2. Being consistent 3. Being Traceable 5. Using clear implementation and documentation 6. Being complete 7. Using priority ranking 1. Using the technical contents of worldwide accepted standards of a particular domain provides the guidelines to guarantee the quality of ontology. 10
Criteria of reusable requirements 4. Being unambiguous 1. using well-known standards 2. Being consistent 3. Being Traceable 5. Using clear implementation and documentation 6. Being complete 7. Using priority ranking 2. It means there is no conflicts between different requirements specifications [7]. 11
Criteria of reusable requirements 4. Being unambiguous 1. using well-known standards 2. Being consistent 3. Being Traceable 5. Using clear implementation and documentation 6. Being complete 7. Using priority ranking 3. The ontology is traceable if there is explicit links between requirements that define the dependency relationships between the requirements in bidirectional manner (back and forth) [7][8] 12
Criteria of reusable requirements 4. Being unambiguous 1. using well-known standards 2. Being consistent 3. Being Traceable 5. Using clear implementation and documentation 6. Being complete 7. Using priority ranking 4. It means all the parties (analysts and stakeholders) agree on the same meaning. 13
Criteria of reusable requirements 4. Being unambiguous 1. using well-known standards 2. Being consistent 3. Being Traceable 5. Using clear implementation and documentation 6. Being complete 7. Using priority ranking 5. The ontology should be written in a clear and widely known language. Example: (OWL) AND the documentation should be easy to understand by analysts and stakeholders. 14
Criteria of reusable requirements 4. Being unambiguous 2. Being consistent 6. Being complete 1. using well-known standards 3. Being Traceable 5. Using clear implementation and documentation 7. Using priority ranking 6. All the necessary requirements are included. 15
Criteria of reusable requirements 4. Being unambiguous 2. Being consistent 6. Being complete 1. Using well-known standards 3. Being Traceable 5. Using clear implementation and documentation 7. Using priority ranking 7. Each requirement has a priority and an expected frequency of changes. 16
Criteria of reusable ontologies Which requirements ontologies have been reused in other studies? What are the criteria of the reused requirements ontologies? 17
Examples of reusable requirements ontologies (1) Dzungand Ohnishi [11] Contribution an ontology-based tool which extracts the initial requirements from the written stakeholders interviews. Requirements type Scope RE activity Reusability Criteria Reused in functional requirements Small Elicitation -consistent -traceable -unambiguous -well documented -implemented in well known language (OWL) Study in [12] reused the same ontology-based tool for education management system. 18
Examples of reusable requirements ontologies (1) Predefined reasoning rules of [11] 1. Complementary rule x y.(complementary(x,y) (y Req)) (x Req) 2. Supplementary rule x y.(supplementary(x,y) (x Req)) (y Req) 19
Examples of reusable requirements ontologies (1) Predefined reasoning rules of [11] 3. Aggregation Rule x y.(aggregation(x,y) (y Req)) (x Req) 4. Inheritance rule y x.(inheritance(x,y) (x Req)) (y Req) 20
Examples of reusable requirements ontologies (1) Predefined reasoning rules of [11] 5. Inconsistency rule x y.(inconsistency(x,y) (x Req) (y Req)) ((x Req) (y Req)) ((x Req) (y Req)) 6. Redundancy rule x y.(redundancy(x,y) (x Req) (y Req)) ((x Req) (y Req)) ((x Req) (y Req)) 21
Examples of reusable requirements ontologies (1) 1 2 3 4 An example of requirements ontology for an online store system [11] An example of checking requirements with ontology [11] 22
Examples of reusable requirements ontologies (2) Wang et al. [9] Contribution Requirements type Scope RE activity Reusability Criteria Reused in A QoS Ontology Cooperated with Feature Models Non-functional requirements Large/industrial Elicitation -using ISO/IEC 9126 quality model -using different priorities -well documented -implemented in well known language The model was reused totally in [10] for requirements elicitation 23
Discussion and Conclusion Most of the reused ontologies are functional requirements ontologies. Requirements ontologies are mostly reused for requirements elicitation purpose. Some authors reused their own requirements ontologies in their other works. Reusing requirements ontologies is not popular. Requirements ontologies could be reused partially or totally. Most of the authors stated that comparing to the gained advantages, the effort and time spent on reusing the ontologies were small. 24
References 1. Dermeval, D., Vilela, J., Bittencourt, I. I., Castro, J., Isotani, S., Brito, P., & Silva, A. (2016). Applications of ontologies in requirements engineering: a systematic review of the literature. Requirements Engineering, 21(4), 405-437. 2. Pacheco, C., Garcia, I., Calvo-Manzano, J. A., & Arcilla, M. (2017). Reusing functional software requirements in smallsized software enterprises: a model oriented to the catalog of requirements. Requirements Engineering, 22(2), 275-287. 3. Goldin, L., & Berry, D. M. (2015). Reuse of requirements reduced time to market at one industrial shop: a case study. Requirements Engineering, 20(1), 23-44. 4. Chernak, Y. (2012, June). Requirements reuse: the state of the practice. In Software Science, Technology and Engineering (SWSTE), 2012 IEEE International Conference on (pp. 46-53). IEEE. 5. Pohl, K., Böckle, G., & van Der Linden, F. J. (2005). Software product line engineering: foundations, principles and techniques. Springer Science & Business Media. 6. Blomqvist, E., Hitzler, P., Janowicz, K., Krisnadhi, A., Narock, T., & Solanki, M. (2016). Considerations regarding Ontology Design Patterns. Semantic Web, 7(1), 1-7. 7. Lauesen, S. (2001). Software Requirements: Styles and Techniques 8. de Almeida Falbo, R., & Nardi, J. C. (2008). Evolving a software requirements ontology. In XXXIV Conferencia Latinoamericana de Informática CLEI 2008(pp. 300-309). 25
References 9. Wang, T., Si, Y., Xuan, X., Wang, X., Yang, X., Li, S., & Kavs, A. J. (2010, November). A QoS ontology cooperated with feature models for non-functional requirements elicitation. In Proceedings of the Second Asia-Pacific Symposium on Internetware (p. 17). ACM. 10. Wohlrab, R., de Gooijer, T., Koziolek, A., & Becker, S. (2014, August). Experience of pragmatically combining RE methods for performance requirements in industry. In Requirements Engineering Conference (RE), 2014 IEEE 22nd International (pp. 344-353). IEEE. 11. Dzung, D. V., & Ohnishi, A. (2009, November). Ontology-based reasoning in requirements elicitation. In Software Engineering and Formal Methods, 2009 Seventh IEEE International Conference on (pp. 263-272). IEEE. 12. Dzung, D. V., & Ohnishi, A. (2012, December). A verification method of elicited software requirements using requirements ontology. In Software Engineering Conference (APSEC), 2012 19th Asia-Pacific (Vol. 1, pp. 553-558). IEEE.. 26
Thank you,,, Any questions? 27