Identification of Design Principles

This report identifies those design principles for a (possibly new) query and transformation language for the Web supporting inference that are considered essential. Based upon these design principles an initial strawman is selected. Scenarios for querying the Semantic Web illustrate the design principles and their reflection in the initial strawman, i.e., a first draft of the query language to be designed and implemented by the REWERSE working group I4

The state-of-practice in requirements specification: an extended interview study at 12 companies

Requirements specifcation is a core activity in the requirements engineering phase of a software development project. Researchers have contributed extensively to the feld of requirements specifcation, but the extent to which their proposals have been adopted in practice remains unclear. We gathered evidence about the state of practice in requirements specifcation by focussing on the artefacts used in this activity, the application of templates or guidelines, how requirements are structured in the specifcation document, what tools practitioners use to specify requirements, and what challenges they face. We conducted an interview-based survey study involving 24 practitioners from 12 diferent Swedish IT companies. We recorded the interviews and analysed these recordings, primarily by using qualitative methods. Natural language constitutes the main specifcation artefact but is usually accompanied by some other type of instrument. Most requirements specifcations use templates or guidelines, although they seldom follow any fxed standard. Requirements are always structured in the document according to the main functionalities of the system or to project areas or system parts. Diferent types of tools, including MS Ofce tools, are used, either individually or combined, in the compilation of requirements specifcations. We also note that challenges related to the use of natural language (dealing with ambiguity, inconsistency, and incompleteness) are the most frequent challenges that practitioners face in the compilation of requirements specifcations. These fndings are contextualized in terms of demographic factors related to the individual interviewees, the organization they are afliated with, and the project they selected to discuss during our interviews. A number of our fndings have been previously reported in related studies. These fndings show that, in spite of the large number of notations, models and tools proposed from academia for improving requirements specifcation, practitioners still mainly rely on plain natural language and general-purpose tool support. We expect more empirical studies in this area in order to better understand the reason of this low adoption of research results.This paper has been funded by the Spanish Ministerio de Ciencia e Innovación under project/funding scheme PID2020-117191RB-I00/AEI/.Peer ReviewedPostprint (published version

Challenging incompleteness of performance requirements by sentence patterns

Performance requirements play an important role in software development. They describe system behavior that directly impacts the user experience. Specifying performance requirements in a way that all necessary content is contained, i.e., the completeness of the individual requirements, is challenging, yet project critical. Furthermore, it is still an open question, what content is necessary to make a performance requirement complete. To address this problem, we introduce a framework for specifying performance requirements. This framework (i) consists of a unified model derived from existing performance classifications, (ii) denotes completeness through a content model, and (iii) is operationalized through sentence patterns. We evaluate both the applicability of the framework as well as its ability uncover incompleteness with performance requirements taken from 11 industrial specifications. In our study, we were able to specify 86% of the examined performance requirements by means of our framework. Furthermore, we show that 68% of the specified performance requirements are incomplete with respect to our notion of completeness. We argue that our framework provides an actionable definition of completeness for performance requirements

Taming Uncertainty in the Assurance Process of Self-Adaptive Systems: a Goal-Oriented Approach

Goals are first-class entities in a self-adaptive system (SAS) as they guide the self-adaptation. A SAS often operates in dynamic and partially unknown environments, which cause uncertainty that the SAS has to address to achieve its goals. Moreover, besides the environment, other classes of uncertainty have been identified. However, these various classes and their sources are not systematically addressed by current approaches throughout the life cycle of the SAS. In general, uncertainty typically makes the assurance provision of SAS goals exclusively at design time not viable. This calls for an assurance process that spans the whole life cycle of the SAS. In this work, we propose a goal-oriented assurance process that supports taming different sources (within different classes) of uncertainty from defining the goals at design time to performing self-adaptation at runtime. Based on a goal model augmented with uncertainty annotations, we automatically generate parametric symbolic formulae with parameterized uncertainties at design time using symbolic model checking. These formulae and the goal model guide the synthesis of adaptation policies by engineers. At runtime, the generated formulae are evaluated to resolve the uncertainty and to steer the self-adaptation using the policies. In this paper, we focus on reliability and cost properties, for which we evaluate our approach on the Body Sensor Network (BSN) implemented in OpenDaVINCI. The results of the validation are promising and show that our approach is able to systematically tame multiple classes of uncertainty, and that it is effective and efficient in providing assurances for the goals of self-adaptive systems

An analysis of the requirements traceability problem

In this paper1, we investigate and discuss the underlying nature of the requirements traceability problem. Our work is based on empirical studies, involving over 100 practitioners, and an evaluation of current support. We introduce the distinction between pre-requirements specification (pre-RS) traceability and post-requirements specification (post-RS) traceability, to demonstrate why an all-encompassing solution to the problem is unlikely, and to provide a framework through which to understand its multifaceted nature. We report how the majority of the problems attributed to poor requirements traceability are due to inadequate pre-RS traceability and show the fundamental need for improvements here. In the remainder of the paper, we present an analysis of the main barriers confronting such improvements in practice, identify relevant areas in which advances have been (or can be) made, and make recommendations for research