Improving Agile Software Development with Domain Ontologies

Abstract

In this paper we propose to apply domain ontologies in agile software development to reduce the ambiguity caused by using natural language as ubiquitous language to report user stories. To justify and demonstrate our approach, we present a case study that combines Scrum and Behaviour-Driven Development (BDD) in the development of an educational support system, which was built to support the activities of the Medicine Programme of Federal University of São Carlos (UFSCar) in Brazil. Starting from a reference ontology for the Higher Education domain, we gradually specialized this ontology for this programme. Since we selected the Evaluation Management module of this system for our case study, we applied the Evaluation Process Ontology to that programme, and defined user stories to identify the feature set to be implemented. For evaluation and validation purposes, we assessed the quality of all ontologies used in this work according to structural and functional dimensions.

Ambiguity in user stories: A systematic literature review

“…According to the Merriam-Webster dictionary, ambiguity exists when a word or expression can be understood in two or more possible ways [30]. In Software Engineering, ambiguity has been described as requirements that do not have a clear single meaning [28,[31][32][33], but also as referring to inconsistency in requirements [34] and missing requirements [35]. Ambiguity is inherent in natural language, yet, the issue is considered a serious problem in software development because ambiguity in requirements might not always be easily recognized [36][37][38].…”

“…Despite empirical support for these benefits (e.g., [18,19,25,26]), several studies showed that user stories are prone to ambiguity [24,[26][27][28]. Based on these studies, we describe ambiguity as problems regarding the articulation of requirements as user stories, which cause doubtful, imprecise, and multiple interpretations of these requirements.…”

A Case Study in the Banking Sector: An Ontology for the Selection of Agile and Lean Software Development Methodologies

“…Therefore, the ontologies developed in [7,16,32,40] are implemented in the sub-parts of the DS in general, which include: collaboration, workflow, process evaluation, cooperative design, and remediation. In agreement with [22,23], the ontologies developed to ensure the traceability of the requirements in the DSA; Whereas, in [38] consider the types of requirements and their options for evaluating the time and cost of entering the data on traceability, the difference between traceability, the existence of points of view of practical benefits, problems in the organization and support of trade trusts. On the other hand, the ontology for requirements allows giving an intelligence support guide of the techniques to be used and an evaluation of the quality metrics of the traceability requirements.…”

Building an OWL Ontology Step By Step for Lean-Based Software Development

“…In other words, an ontology is the representation of a vocabulary that contains a formal definition of types, properties, relationships, axioms and instances between concepts, data and entities categorized in classes and subclasses involved in a given context. This is because an ontological model is a powerful mechanism used to represent knowledge and encode its meaning in order to provide a shared understanding between people, organizations and systems by providing a formal, explicit, flexible and understandable vocabulary for anyone who wants to implement it, while avoiding ambiguity [27,31]. This paper considers the five phases of ontology development, proposed by [18], as the basis for the creation of the LSD ontology described below:…”