Knowledge Management for Informally Structured Domains: Challenges and Proposals

Eliciting requirements of products or solutions in informally structured domains is a highly creative and complex activity due to the inherent characteristics of these domains, such as the great quantities of tacit knowledge used by domain specialists, the dynamic interaction between domain specialists and their environment in order to solve problems, the necessity of these solutions of products to be developed by teams of specialists and the asymmetry of knowledge between domain specialists and requirements engineers. The knowledge management discipline promotes an integrated approach in order to face these challenges; therefore, a strategy for addressing requirements elicitation that incorporates techniques and methods of this discipline has been proposed as a serious approach to deal with those challenges. The valuable results of the application of the strategy in real cases prove empirical insights about its utility

Selection of third party software in Off-The-Shelf-based software development: an interview study with industrial practitioners

The success of software development using third party components highly depends on the ability to select a suitable component for the intended application. The evidence shows that there is limited knowledge about current industrial OTS selection practices. As a result, there is often a gap between theory and practice, and the proposed methods for supporting selection are rarely adopted in the industrial practice. This paper's goal is to investigate the actual industrial practice of component selection in order to provide an initial empirical basis that allows the reconciliation of research and industrial endeavors. The study consisted of semi-structured interviews with 23 employees from 20 different software-intensive companies that mostly develop web information system applications. It provides qualitative information that help to further understand these practices, and emphasize some aspects that have been overlooked by researchers. For instance, although the literature claims that component repositories are important for locating reusable components; these are hardly used in industrial practice. Instead, other resources that have not received considerable attention are used with this aim. Practices and potential market niches for software-intensive companies have been also identified. The results are valuable from both the research and the industrial perspectives as they provide a basis for formulating well-substantiated hypotheses and more effective improvement strategies.Peer ReviewedPostprint (author's final draft

OntoEng: A design method for ontology engineering in information systems

This paper addresses the design problem relating to ontology engineering in the discipline of information systems. Ontology engineering is a realm that covers issues related to ontology development and use throughout its life span. Nowadays, ontology as a new innovation promises to improve the design, semantic integration, and utilization of information systems. Ontologies are the backbone of knowledge-based systems. In addition, they establish sharable and reusable common understanding of specific domains amongst people, information systems, and software agents. Notwithstanding, the ontology engineering literature does not provide adequate guidance on how to build, evaluate, and maintain ontologies. On the basis of the gathered experience during the development of V4 Telecoms Business Model Ontology as well as the conducted integration of the related literature from the design science paradigm, this paper introduces OntoEng and its application as a novel systematic design method for ontology engineering

Impactful learning: exploring the value of informal learning experiences to improve the learning potential of international research projects.

The Horizon 2020 (H2020) is the largest EU funded research programme, which supports mobility of international researchers through secondments to engage in collaborative research activities to enhance individual and collective research capacity within the EU. This paper explores how an analysis of secondees’ informal learning experiences can highlight opportunities for increasing individual and collective learning capacity of an international partnership and achievement of project objectives. A thematic analysis method (Miles and Huberman, 1994), was applied to 19 secondee’s individual learning reports. The main findings discussed three themes elicited through secondees informal learning, including living and working in a host country and developing an academic career. The paper outlines practice, policy and research implications for improving the learning potential of international research projects

Reusing Scenario Based Approaches in Requirement Engineering Methods: CREWS Method Base

National audienceIn the CREWS project four different scenario-based approaches have been developed with the aim of supporting system requirements acquisition and validation in a systematic way. Two approaches deal with the requirements acquisition from real world scenes [Haumer 98] and from natural language scenario descriptions [Rolland 97], [Rolland 98a]. Two other approaches deal with the requirements validation through systematic scenario generation coupled to scenario walkthrough [Sutcliffe 98] and scenario animation [Dubois 98]. The project hypothesis is that each of the approaches might be useful in specific project situations which are not well tackled by existing analysis methods and therefore, that it is worth looking for the integration of such approaches in current methods. This shall lead to an enhancement of the existing methods with scenario-based techniques. Moreover, in the CREWS project we have proposed a framework for classifying scenarios [Rolland 98b] as a way to explore the issues underlying scenario based approaches in Requirements Engineering (RE). The application of this framework on several scenario based approaches proven the existence of the variety of products and practices of scenarios. We situate our work in the situational method engineering domain. The situational method engineering discipline aims at defining information systems development methods by reusing and assembling different existing method fragments. This approach allows to construct modular methods which can be modified and augmented to meet the requirements of a given situation. Following this approach, a method is viewed as a collection of method fragments [Rolland 96], [Harmsen 94], [Harmsen 97]. New methods can be constructed by selecting fragments from different methods which are the more appropriate to a given situation [Brinkkemper 98], [Plihon 98]. Thus, method fragments are the basic building blocks which allow to define methods in a modular way. In our work we are interested in specific method fragments, namely scenario based approaches, that we call scenario method chunks. The objective of our work is to develop an approach for integrating different kinds of scenarios as method components into usual RE methods. To achieve this goal we propose to represent the scenario based approaches in a method base as method components called scenario method chunks. We need also to define the approach for retrieving relevant scenario method chunk for the situation at hand. Finally, we need to define the approach supporting the integration of the retrieved component with the existing RE method or with another method component

Overview of methodologies for building ontologies

A few research groups are now proposing a series of steps and methodologies for developing ontologies. However, mainly due to the fact that Ontological Engineering is still a relatively immature discipline, each work group employs its own methodology. Our goal is to present the most representative methodologies used in ontology development and to perform an analysis of such methodologies against the same framework of reference. So, the goal of this paper is not to provide new insights about methodologies, but to put it all in one place and help people to select which methodology to use

How do software architects consider non-functional requirements: an exploratory study

© 2012 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.Dealing with non-functional requirements (NFRs) has posed a challenge onto software engineers for many years. Over the years, many methods and techniques have been proposed to improve their elicitation, documentation, and validation. Knowing more about the state of the practice on these topics may benefit both practitioners' and researchers' daily work. A few empirical studies have been conducted in the past, but none under the perspective of software architects, in spite of the great influence that NFRs have on daily architects' practices. This paper presents some of the findings of an empirical study based on 13 interviews with software architects. It addresses questions such as: who decides the NFRs, what types of NFRs matter to architects, how are NFRs documented, and how are NFRs validated. The results are contextualized with existing previous work.Peer ReviewedPostprint (author’s final draft