Context: Quality requirements (QRs) are a topic of constant discussions both in industry and academia. Debates entwine around the definition of quality requirements, the way how to handle them, or their importance for project success. While many academic endeavors contribute to the body of knowledge about QRs, practitioners may have different views. In fact, we still lack a consistent body of knowledge on QRs since much of the discussion around this topic is still dominated by observations that are strongly context-dependent. This holds for both academic and practitioners' views. Our assumption is that, in consequence, those views may differ. Objective: We report on a study to better understand the extent to which available research statements on quality requirements, as found in exemplary peer-reviewed and frequently cited publications, are reflected in the perception of practitioners. Our goal is to analyze differences, commonalities, and context-dependent grey areas in the views of academics and practitioners to allow a discussion on potential misconceptions (on either sides) and opportunities for future research. Method: We conducted a survey with 109 practitioners to assess whether they agree with research statements about QRs reflected in the literature. Based on a statistical model, we evaluate the impact of a set of context factors to the perception of research statements. Results: Our results show that a majority of the statements is well respected by practitioners; however, not all of them. When examining the different groups and backgrounds of respondents, we noticed interesting deviations of perceptions within different groups that may lead to new research questions. Conclusions: Our results help identifying prevalent context-dependent differences about how academics and practitioners view QRs and pinpointing statements where further research might be useful.

This dataset contains additional material for the research paper "The Leprechauns of Quality Requirements: Beliefs and Dispersion in Academia and Practice". More specifically, it contains four files: Questionaire_Print version.pdf: The survey instrument that we used for the study. Leprechauns.gephi: A Gephi file containing the graphs that we used in the paper. data.csv: A csv file containing the answers of all survey participants. processing_script.R: An R script that we used to analyse and visualize the data.

Context: Designing new architectures is a challenging task. A common and also effective approach for this task is to apply architectural design experience. Problem: If, however, architectural design experience is not available, two major problems arise: (i) how can we identify architecturally significant requirements (ASRs) and (ii) how can we identify architectural design decisions (ADDs) which address those ASRs?Approach: To address these problems, we propose an approach to systematically elicit ASRs and identify ADDs based on grounded theory (GT). By using GT, our approach provides transparency and fosters objectivity: ASRs as well as ADDs are elicited by qualitative data analysis and each ADD is motivated by corresponding ASRs. While objectivity addresses the correctness of the identified ASRs and ADDs, transparency allows for assessing ADDs with respect to the corresponding ASRs. Evaluation: We evaluate our approach by a case study in which we apply it to develop an architecture in the context of the technology trend "appification".

There is a significant discussion on categorizing requirements in academia. Most commonly, requirements are categorized into functional requirements (FRs) and non-functional requirements (NFRs). However, as pointed out by Glinz and Broy, there is a terminological confusion about the underlying terms. This disagreement over categorizing requirements is not only prevalent in research, but it also influences how requirements are elicited, documented, and validated in practice. As a matter of fact, up until now, there does not exist a commonly accepted approach for the NFR-specific elicitation, documentation, and analysis; so-called NFRs are usually described vaguely, remain often not quantified, and as a result remain difficult to analyze and test. Furthermore, so-called NFRs are often retrofitted in the development process or pursued in parallel with, but separately from functional requirements and, thus, are implicitly managed with little or no consequence analysis. This limited focus on so-called NFRs can result in the long run in high maintenance costs. Although the importance of so-called NFRs for software and systems development is widely accepted, the discourse in academia is still dominated by how to categorize requirements. One point of view is that a categorization should be grounded in methodological reasons and we should rather base a requirements categorization on a system model. The underlying argument is that if we base a categorization on a system model, we can precisely specify requirements in terms of properties of systems, where properties are represented by logical predicates. The goal of the dissertation is to address the following two major questions: First, is a requirements categorization based on a system model adequate for requirements found in practice? With adequate, we mean that the categorization is applicable for industrial requirements and supports subsequent development activities. Second, how can a requirements categorization based on a system model be operationalized for subsequent development activities? To this end, we contribute a detailed analysis how practitioners handle and categorize requirements, elaborate the reasons for and resulting consequences on the overall development process, analyze the adequacy of a categorization based on a system model, analyze problems with requirements categorizations in practice, and present and evaluate an approach that embeds such a categorization for requirements in subsequent development activities.

The number of papers and articles on goals would suggest that goal-oriented requirements engineering is a well understood and mature area within the requirements engineering discipline. In particular, there is a wealth of published material on formal goal modelling approaches. However, the uptake of the goal approaches advocated by academics and researchers within real world settings appears to be quite low. Where goals are used in industrial practice their use is mainly informal and the methods used are inconsistent. There appears to be a significant gap between research and practice in the use of goals within requirements engineering. A two-part study was undertaken to check whether there is evidence to support this view of a disconnection between research and industry. Firstly, a literature survey of requirements engineering papers about goals reveals a large body of published material, but the majority has little industrial involvement. Secondly, a questionnaire completed by experienced requirements engineering practitioners suggests that use of goals in practice is inconsistent, informal, and rarely utilises formal modelling approaches. This paper proposes future work that would close the gap between research and practice in the use of goals within requirements engineering.

Non-functional requirements (NFRs) are commonly distinguished from functional requirements by differentiating how the system shall do something in contrast to what the system shall do. This distinction is not only prevalent in research, but also influences how requirements are handled in practice. NFRs are usually documented separately from functional requirements, without quantitative measures, and with relatively vague descriptions. As a result, they remain difficult to analyze and test. Several authors argue, however, that many so-called NFRs actually describe behavioral properties and may be treated the same way as functional requirements. In this paper, we empirically investigate this point of view and aim to increase our understanding on the nature of NFRs addressing system properties. We report on the classification of 530 NFRs extracted from 11 industrial requirements specifications and analyze to which extent these NFRs describe system behavior. Our results suggest that most "non-functional" requirements are not non-functional as they describe behavior of a system. Consequently, we argue that many so-called NFRs can be handled similarly to functional requirements.

Requirements are often divided into functional requirements (FRs) and quality requirements (QRs). However, we still have little knowledge about to which extent this distinction makes sense from a practical perspective. In this paper, we report on a survey we conducted with 103 practitioners to explore whether and, if so, why they handle requirements labeled as FRs differently from those labeled as QRs. We additionally asked for consequences of this distinction w.r.t. the development process. Our results indicate that the development process for requirements of the two classes strongly differs (e.g., in testing). We identified a number of reasons why practitioners do (or do not) distinguish between QRs and FRs in their documentation and we analyzed both problems and benefits that arise from that. We found, for instance, that many reasons are based on expectations rather than on evidence. Those expectations are, in fact, not reflected in specific negative or positive consequences per se. It therefore seems more important that the decision whether to make an explicit distinction or not should be made consciously such that people are also aware of the risks that this distinction bears so that they may take appropriate countermeasures.

Requirements are usually categorized in functional requirements (FRs) and quality requirements (QR). FRs describe "things the product must do" while QRs describe "qualities the product must have". Besides the definition, classification, and representation problems identified by Glinz, there are two further problems with current definitions of quality requirements: (i) the definitions are imprecise and thus difficult to understand and apply, and (ii) the definitions provide no guidance or support for their application in a given organizational context. To tackle these two problems, we propose an approach that - given a quality attribute (e.g., performance) as input - provides a means to specify quality requirements by sentence patterns regarding this quality attribute. In this paper, we contribute a detailed presentation and description of our approach and a discussion of our lessons learnt while instantiating it for performance requirements. Additionally, we give guidance on how to apply our approach for further quality attributes. Through this approach, we aim at encouraging researchers to help us improve the precision of definitions for quality requirements and support practitioners in eliciting and documenting better quality requirements.

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.

Non-functional requirements (NFRs) are commonly distinguished from functional requirements by differentiating how the system shall do something in contrast to what the system shall do. This distinction is not only prevalent in research, but also influences how requirements are handled in practice. NFRs are usually documented separately from functional requirements, without quantitative measures, and with relatively vague descriptions.As a result, they remain difficult to analyze and test.Several authors argue, however, that many so-called NFRs actually describe behavioral properties and may be treated the same way as functional requirements. In this paper, we empirically investigate this point of view and aim to increase our understanding on the nature of NFRs addressing system properties. We report on the classification of 530 NFRs extracted from 11 industrial requirements specifications and analyze to which extent these NFRs describe system behavior.Our results suggest that most "non-functional" requirements are not non-functional as they describe behavior of a system. Consequently, we argue that many so-called NFRs can be handled similarly to functional requirements.

Architectural styles and patterns play an important role in software engineering. One of the most known ones is the layered architecture style. However, this style is usually only stated informally, which may cause problems such as ambiguity, wrong conclusions, and difficulty when checking the conformance of a system to the style. We address these problems by providing a formal, denotational semantics of the layered architecture style. Mainly, we present a sufficiently abstract and rigorous description of layered architectures. Loosely speaking, a layered architecture consists of a hierarchy of layers, in which services communicate via ports. A layer is modeled as a relation between used and provided services, and layer composition is defined by means of relational composition. Furthermore, we provide a formal definition for the notions of syntactic and semantic dependency between the layers. We show that these dependencies are not comparable in general. Moreover, we identify sufficient conditions under which, in an intuitive sense which we make precise in our treatment, the semantic dependency implies, is implied by, or even coincides with the reflexive-transitive closure of the syntactic dependency. Our results provide a technology-independent characterization of the layered architecture style, which may be used by software architects to ensure that a system is indeed built according to that style.

[Background] Requirements Engineering is crucial for project success, and to this end, many measures for quality assurance of the software requirements specification (SRS) have been proposed. [Goal] However, we still need an empirical understanding on the extent to which SRS are created and used in practice, as well as the degree to which the quality of an SRS matters to subsequent development activities. [Method] We studied the relevance of SRS by relying on survey research and explored the impact of quality defects in SRS by relying on a controlled experiment. [Results] Our results suggest that the relevance of SRS quality depends both on particular project characteristics and what is considered as a quality defect; for instance, the domain of safety critical systems seems to motivate for an intense usage of SRS as a means for communication whereas defects hampering the pragmatic quality do not seem to be as relevant as initially thought. [Conclusion] Efficient and effective quality assurance measures must be specific for carefully characterized contexts and carefully select defect classes.

Context: Seamless model-based development provides integrated chains of models, covering all software engineering phases. Non-functional requirements (NFRs), like reusability, further play a vital role in software and systems engineering, but are often neglected in research and practice. It is still unclear how to integrate NFRs in a seamless model-based development. Goal: Our long-term goal is to develop a theory on the specification of NFRs such that they can be integrated in seamless model-based development. Method: Our overall study design includes a multi-staged procedure to infer an empirically founded theory on specifying NFRs to support seamless modeling. In this short paper, we present the study design and provide a discussion of (i) preliminary results obtained from a sample, and (ii) current issues related to the design. Results: Our study already shows significant fields of improvement, e.g., the low agreement during the classification. However, the results indicate to interesting points; for example, many of commonly used NFR classes concern system modeling concepts in a way that shows how blurry the borders between functional and NFRs are. Conclusions: We conclude so far that our overall study design seems suitable to obtain the envisioned theory in the long run, but we could also show current issues that are worth discussing within the empirical software engineering community. The main goal of this contribution is not to present and discuss current results only, but to foster discussions on the issues related to the integration of NFRs in seamless modeling in general and, in particular, discussions on open methodological issues.

Emerging distributed systems such as cloud-based services are characterized by computations over different explicit localities, moving code and data, and a high degree of concurrency. KLAIM is a well-established language that can naturally describe such systems. The KLAIM language is process algebra flavored, allows Linda-based asynchronous communication through distributed tuple spaces, and supports explicit localities as well as code and data mobility. In this work we take some first steps in the quest for a correct-by-construction design process for secure and reliable distributed systems. Such a design process is necessary as more and more safety- and security-critical tasks that need to satisfy mission-critical formal requirements are executed in a distributed setting. We use a rewriting-based approach to formally specify and analyze KLAIM specifications of distributed systems. In particular we: (i) specify the reduction semantics of KLAIM in Maude, (ii) extend the Maude-based specification by making messages first-class citizens, and (iii) describe a second extension that allows true distributed execution of Maude-based KLAIM specifications. We prove that under appropriate weak fairness assumptions all these specifications are stuttering bisimilar and that large classes of logic temporal formulas, namely all CTL⁎∖X formulas, are preserved. By means of an example we show that our approach allows specifying aspects of a distributed system in a Maude-based KLAIM dialect, verifying these specifications using Maude's LTL model checking capabilities, and then executing the verified specifications in a distributed environment. This marks a first step in the quest for a correct-by-construction design process for secure and reliable distributed systems.

Context: In the context of the research and development project ARAMiS, multiple partners from research and industry are collaborating in the development of new methods and technologies in the field of multicore systems. Goal: We designed and executed studies for evaluating the results of the ARAMiS sub-project responsible for requirements engineering: an artifact-based requirements engineering approach, its tooling, and a cross-domain scenario. Method: This evaluation was performed along with the dissemination of the results in the project. The evaluation included two studies aimed at collecting the opinions of the project participants regarding the requirements engineering results from the viewpoints of industry and research. Results: The mainly positive results showed us that the different parts of the requirements engineering approach in this project are being accepted. Conclusions: Nonetheless, especially the results for the scenario revealed some weaknesses, such as the so-called "ARAMiS gap", i.e., a gap between the high-level requirements engineering artifacts and the detailed engineering artifacts.

Software reuse is a challenging and multifaceted topic. Significant research effort has been spent to address technical and organizational aspects. However, adoption of proposed practices and novel approaches often proceeds slowly. Additionally, little is known on how reuse is currently effected in practice and which solutions have proven useful. This paper aims to shed light on the matter by studying the current practice of reuse at Google. We conduct an exploratory study with a total of 49 participants of which 39 answered our online questionnaire and 10 participated in our 1h interviews. We assess reuse practices, success factors and challenges and collect ideas for improvement. We distill our findings to provide practitioners with examples of scalable reuse practices and detail on prerequisites required to implement/tailor a similar reuse approach. Furthermore, we point out open issues to support researchers and practitioners alike to align their efforts for developing solutions.

The job profile of a Software Engineer not only includes so-called "hard-skills" (e.g. specifying, programming, or building architectures) but also "soft skills" like awareness of team effects and similar human factors. These skills are typically hard to teach in classrooms, and current education, hence, mostly focuses on hard rather than soft skills. Yet, since software development is becoming more and more spread across different sites in a globally distributed manner, the importance of soft skills increases rapidly. However, there are only a few practical guides to teach such tacit knowledge to Software Engineering students. In this chapter, the authors describe an approach that combines theoretical lectures, practical experiments, and discussion sessions to fill this gap. They describe the processes of creating, planning, executing, and evaluating these sessions, so that soft skill topics can be taught in a university course. The authors present two example implementations of the approach. The first implementation lets students experience and reflect on group dynamics and team-internal effects in a project situation. The second implementation enables students to understand the challenges of a distributed software development setting. With this knowledge, the authors critically discuss the contribution of experimentation to university teaching.

The various influences on processes and application domains make requirements engineering (RE) inherently complex and difficult to implement. When it comes to define an RE reference model for a company-wide use, we basically have two options: we can establish an activity-based RE approach where we define a blueprint of the relevant RE methods and description techniques, or we can establish an artefact-based approach where we define a blueprint of the RE artefacts rather than a blueprint of the way of creating the artefacts. In the last six years, we have established several artefact-based RE approaches and empirically underpinned the advantages of applying those approaches in industry. Those approaches remain, however, complex as they encompass various modelling concepts, and, in particular, incorporate their particularities of the different application domains, such as the one of business information systems. For this reason, we consolidated the different approaches and established the AMDiRE approach, i.e. the artefact model for domain-independent requirements engineering. AMDiRE includes a detailed artefact model that captures the basic modelling concepts used to specify RE-relevant information, tool support, and a tailoring guideline that guides the creation of the artefacts. To provide a quick overview of the basic concepts of AMDiRE and the underlying principles, this report serves as a Cheat Sheet. This cheat sheet shall facilitate the basic understanding about the fundamentals in artefact orientation and provide an overview of a flexible artefact-based RE approach ready to be applied in practical contexts without focussing on technical details.

Systems whose functionality and services span over multiple, interconnected application domains have become known as cyber-physical system (CPS) and currently receive much attention in research and practice. So far, CPS still come with a variety of development-process-related and technical challenges. These challenges include the interaction between the different domain-specific systems and possible conflicts between their requirements, as well as the choice of appropriate modelling concepts. This paper makes two main contributions: First, we show how such an inter-domain development-process can be structured, beginning with a a model-based requirements engineering approach. In order to illustrate the concepts, this paper provides a continuous example scenario, developed within a group of the respective domain experts, that outlines the future of mobility using technologies currently under development in the ARAMiS project. The intention is to allow for an analysis of interaction and possible interference between domain-specific scenarios as well as the analysis of the relation between derived domain specific scenarios and the global, cross-domain scenario. Second, we provide an analysis of the realisability of the scenario steps according to a set of quality criteria and estimate the respective time horizon, derived from interviews with experts from different domains. The described scenario allows the reification of goals and requirements of CPS for the mobility domain. Moreover, it makes apparent the need for connecting CPS of different domains. Our validation research provides an accompanying resource for future analysis of the interaction between domains and the relation between their requirements as well as teaching requirements engineering in the domain of CPS.

Artefact-based requirements engineering (RE) describes the idea of establishing a company-wide reference model by putting the focus on the RE artefacts and their dependencies rather than dictating a strict process with interconnected methods. Although we could make first empirical studies on the benefits and shortcomings of artefact-based RE, however, we still have little evidence for our first results. The reason is that the conducted case studies focus on the isolated application of artefact-based RE approaches in individual socio-economic contexts and, thus, the findings can hardly be generalised. The contribution of this paper is to report on two conducted replication studies to strengthen our confidence on the benefits and shortcomings of applying artefact orientation in RE. To this end, we replicated an industrial case study with partners from two companies. Those replications form part of a research project where all partners are working with the same artefact-based RE approach and its tool-supported realisation. Our results give deeper insights into artefact-based RE and contribute to a reliable database due to comparability among the studies. This allows for first conclusions on the actual impact artefact orientation has on RE.