Software qualities such as usability or reliability are among the strongest determinants of mobile app user satisfaction and constitute a significant portion of online user feedback on software products, making it a valuable source of quality-related feedback to guide the development process. The abundance of online user feedback warrants the automated identification of quality characteristics, but the online user feedback’s heterogeneity and the lack of appropriate training corpora limit the applicability of supervised machine learning. We therefore investigate the viability of three approaches that could be effective in low-data settings: language patterns (LPs) based on quality-related keywords, instructions for crowdsourced micro-tasks, and large language model (LLM) prompts. We determined the feasibility of each approach and then compared their accuracy. For the complex multiclass classification of quality characteristics, the LP-based approach achieved a varied precision (0.38–0.92) depending on the quality characteristic, and low recall; crowdsourcing achieved the best average accuracy in two consecutive phases (0.63, 0.72), which could be matched by the best-performing LLM condition (0.66) and a prediction based on the LLMs’ majority vote (0.68). Our findings show that in this low-data setting, the two approaches that use crowdsourcing or LLMs instead of involving experts achieve accurate classifications, while the LP-based approach has only limited potential. The promise of crowdsourcing and LLMs in this context might even extend to building training corpora.

The farming domain has seen a tremendous shift to-wards digital solutions. However, capturing farmers' requirements regarding Digital Farming (DF) technology remains a difficult task due to domain-specific challenges. Farmers form a diverse and international crowd of practitioners who use a common pool of agricultural products and services, which means we can consider the possibility of applying Crowd-based Requirements Engineering (CrowdRE) for DF: CrowdRE4DF. We found that online user feedback in this domain is limited, necessitating a way of capturing user feedback from farmers in situ. Our solution, the Farmers' Voice application, uses speech-to-text, Machine Learning (ML), and Web 2.0 technology. A preliminary evaluation with five farmers showed good technology acceptance, and accurate transcription and ML analysis even in noisy farm settings. Our findings help to drive the development of DF technology through in-situ requirements elicitation.

Our requirements engineering (RE) community has known for decades that the success or failure of RE methods heavily depends on the context in which they are applied. Thus, many experiences have been gained and shared in the community that reflect which RE methods are suitable for a specific context, such as embedded systems development (e.g., automotive or military domain) or information systems development (e.g., banking or flight control domain). Nowadays, in times of smart cities and their counterpart smart rural areas, where newly introduced IT systems have a strong effect on our society, a new and challenging context arises for RE, which opens up new research questions. As a contribution to this situation and to foster discussions in our community about whether our RE methods are appropriate in this new "social context", this perspective paper reflects on the state of the art and on our own experiences in applying RE in the context of smart rural areas. These results might also pertain in the context of smart cities that pose similar challenges to RE. In addition, we present a framework comprising both an initial classification of social contexts, particularly their end users, and a classification for RE methods. Example usage scenarios illustrate how this framework helps to reflect on the suitability of our RE methods, and, if necessary, provides the basis for adapting them or creating new ones. Finally, we outline a roadmap with research questions and related activities with which we want to encourage our community to perform the proposed research activities in order to enrich our body of experiences and adapt our methods to this highly relevant context.

Many User Experience (UX) activities are carried out during requirements engineering phases, e.g. understanding and assessing the UX of existing systems, and eliciting functional and non-functional requirements that improve UX. These activities are typically performed by requirements engineers who are non-UX experts. It is necessary to provide a good UX in order to ensure long-term motivation of users, especially in business applications. UX has various characteristics of differing importance; it can be difficult for RE engineers to grasp all characteristics of UX and to judge which characteristics are important and which need to be improved. We propose a two-step approach to solve these difficulties. The first step is the definition of a UX quality model and corresponding metrics. We propose an approach to calculate the UX score of a business application using the value of these metrics. The second step is a process to identify insufficient characteristics within the calculated UX score. In this paper we present the aforementioned approach to collect and calculate the UX score of a product, show how to identify serious UX-related problems as part of requirements engineering activities, and present the results obtained from an initial validation of our quality model and related questionnaire. With our approach, we enable RE experts who are non-UX experts to find the necessary requirements to improve UX.

We are now living in the era of digital transformation: Innovative and digital business models are transforming the global business world and society. However, the authors of this paper have perceived barriers that prevent requirements engineers from contributing properly to the development of the software systems that underpin the digital transformation. We also realized that breaking down each of these barriers would contribute to requirements engineering (RE) becoming ubiquitous in certain dimensions: RE everywhere, with everyone, for everything, automated, accepting openness, and cross-domain. In this paper, we analyze each dimension of ubiquity in the scope of the interaction between requirements engineers and end users. In particular, we point out the transformation that is required to break down each barrier, present the perspective of the scientific community and our own practical perspective, and discuss our vision on how to achieve this dimension of ubiquity. Our goal is to raise the interest of the research community in providing approaches to address the barriers and move towards ubiquitous RE.

[Context and motivation] Research on eliciting requirements from a large number of online reviews using automated means has focused on functional aspects. Assuring the quality of an app is vital for its success. This is why user feedback concerning quality issues should be considered as well [Question/problem] But to what extent do online reviews of apps address quality characteristics? And how much potential is there to extract such knowledge through automation? [Principal ideas/results] By tagging online reviews, we found that users mainly write about "usability" and "reliability", but the majority of statements are on a subcharacteristic level, most notably regarding "operability", "adaptability", "fault tolerance", and "interoperability". A set of 16 language patterns regarding "usability" correctly identified 1,528 statements from a large dataset far more efficiently than our manual analysis of a small subset. [Contribution] We found that statements can especially be derived from online reviews about qualities by which users are directly affected, although with some ambiguity. Language patterns can identify statements about qualities with high precision, though the recall is modest at this time. Nevertheless, our results have shown that online reviews are an unused Big Data source for quality requirements.

The technical or organizational enforcement of security policies is a necessity for modern enterprises such as DATEV eG. However, security policy specification is challenging, especially for users inexperienced in security. The provision of project-and domain-specific security policy templates can support users in the specification of security policies. However, existing elicitation approaches focus on general security requirements or risk assessment and do not support domain-specific policy template derivation. In this paper, we present a methodology for eliciting and deriving such security policy templates. We use and adapt established techniques known from requirements engineering to elicit assets, threats, and countermeasures. The policy templates, derived from the gathered information, are used to instantiate domain-specific security requirements at run-time. We successfully applied our method in an industrial case study at DATEV eG to show its principle applicability.

Many systems in the industrial automation domain include information systems. They manage manufacturing processes and control numerous distributed hardware and software components. In current practice, the development and reuse of such systems is costly and time-consuming, due to the variability of systems' topology and processes. Up to now, product line approaches for systematic modeling and management of variability have not been well established for such complex domains.

Warehouse management systems (WMS) play a critical role in supply chains and large production processes. WMS pose two crucial challenges for variability modeling and management: Firstly, the physical configuration of each warehouse differs significantly. Numerous different electronic devices like controllers, sensors, and motors are used to automate warehouses. Secondly, the processes running in a warehouse demand control and coordination of these various software and hardware components. These processes have different configurations according to customer requirements. This paper reports on our experiences when applying variability modeling techniques in WMS, in order to improve the degree of reuse and shorten the delivery time to customers. Feature modeling is used to extract commonalities and variability in WMS. More than 200 features were identified, and categorized into three hierarchical layers. Furthermore, we linked the feature models to assets, and utilize feature models to support product derivation. Then, the lessons learned from the experiences are discussed. Based on these experiences, we conclude that feature modeling can be applied nicely for scoping features and tracing features to assets, but is not comprehensive enough to support automated configuration during product derivation in WMS.

In existing usage control policy frameworks, policies consisting of authorizations and obligations are specified at a low level of abstraction. As a consequence, these policy specifications become long and complex since they reference many technical elements of the system such as operating system calls or web-service invocations. Due to this complexity, it is difficult for policy authors to assess if the policies they specify are complete and correct in order to achieve their high-level usage control goals. In this paper we describe our approach for specification and refinement of usage control policies that addresses this complexity problem. In our approach, high-level usage control policies are specified considering an abstract system model and automatically refined with the help of policy refinement rules to implementation-level policies. The input of our refinement rules is the abstract system model, the concrete system model, the system refinement steps from abstract to concrete, and the abstract usage control policies. We show the application of our approach in a case study of a supply chain scenario implemented using BPMN. In our case study high-level usage control policies are automatically refined to implementation-level policies that can be enforced in a BPMN engine.

Software requirements specifications play a crucial role in software development projects. Especially in large projects, these specifications serve as a source of communication and information for a variety of roles involved in downstream activities like architecture, design, and testing. This vision paper argues that in order to create high-quality requirements specifications that fit the specific demands of successive document stakeholders, our research community needs to better understand the particular information needs of downstream development roles. In this paper, the authors introduce the idea of view-based requirements specifications. Two scenarios illustrate (1) current problems and challenges related to the research underlying the envisioned idea and (2) how these problems could be solved in the future. Based on these scenarios, challenges and research questions are outlined and supplemented with current results of exemplary user studies. Furthermore, potential future research is suggested, which the community should perform to answer the research questions as part of a research agenda.

SUMMARY Business processes need to be agile and flexible to help organizations stay competitive. For this purpose, SOA promises the reuse of already existing information system functionality for enabling enterprises to change the business processes more quickly. However, many promises made by SOA authors have not found their way into practice, because methodological guidance that constructively assures a more successful SOA application is still missing. In this article, service‐oriented requirements engineering is therefore introduced as a discipline aiming at a better and more systematic handling and alignment of SOA and Business Process Management. Our industrial experience in this regard is also described. Copyright © 2011 John Wiley & Sons, Ltd.

Providing high-quality software within budget is a goal pursued by most software companies. Incomplete requirements specifications can have an adverse effect on this goal and thus on a company's competitiveness. Several empirical studies have investigated the effects of requirements engineering methods on the completeness of a specification. In order to increase this body of knowledge, we suggest using an objective evaluation scheme for assessing the completeness of specification documents, as objectifying the term completeness facilitates the interpretation of evaluations and hence comparison among different studies. This paper reports experience from applying the scheme to a student experiment comparing a use case with a textual approach common in industry. The statistical analysis of the specification's completeness indicates that use case descriptions lead to more complete requirements specifications. We further experienced that the scheme is applicable to experiments and delivers meaningful results.

Early orientation towards tasks of the application domain to be supported by a software system has been proposed as a fruitful means for achieving more appropriate and usable systems as well as for focusing the requirements engineering process. Besides goal orientation, task orientation has therefore been recognized as a promising concept for assuring more completeness and correctness of requirements specifications, and better integration with usability engineering issues. In this paper, we present experiences made with the task-oriented requirements engineering framework ldquoTORErdquo in four different case studies. These case studies were selected based on their contextual specifics, like service orientation or ambient intelligence, that might impose certain challenges on task-oriented RE. As a lesson learned, we experienced TORE to be highly beneficial even in systems that do not seem to be ldquotraditionalrdquo information systems at first glance. However, we also identified limitations that call for necessary adaptations.

Business process modeling notations are used in requirements engineering to specify business processes that should be supported by the system under development. Comparisons of business process modeling notations with regard to their concepts do exist, but to our knowledge, little evaluation has taken place regarding their effectiveness and efficiency for typical requirements engineering tasks. Therefore, we set up experiments examining UML activity diagrams (ACTs) and event-driven process chains (EPCs) both from a requirements engineer's perspective with a focus on model creation and from a customer's or end user's perspective with a focus on model understandability. The experiments were conducted as a blocked subject-object study, where the participants had to solve several characteristic tasks. The results were then analyzed by means of statistical analysis methods. In the case of the requirements engineer, we were able to show that ACTs perform better than EPCs. In the case of the customer or end user, we cannot make a clear statement.

The service-oriented paradigm typically separates the development of systems into service engineering and application engineering. In our opinion, these two disciplines cannot be completely separated, as otherwise, there is no assurance that services provided by service engineering can actually be used by application engineering. In this paper, we describe service-oriented requirements engineering (SORE) as an appropriate means for mediating between the two disciplines, and we identify the provision of service capabilities on the right level of abstraction and variability as the most crucial aspects SORE has to assure. For this purpose, we present the adoption of product line technology in service- oriented architecture and its closer alignment with business process management as a promising approach, and list related principles as well as challenges we plan to address in our ongoing research.

S.639-648

Without distinguishing unstable from stable features and anticipating likely new features, building evolvability into software systems can be time-consuming and, above all, ineffective. This paper introduces a method based on a software evolution model whose goal is to help requirements engineers and product managers identify the unstable features of an embedded system and anticipate its potential adaptation needs in the future, with the aim of planning for changes beforehand. The core characteristic of this method is its support for systematic reasoning on requirements volatility and planning for changes. An application of the method in the domain of assisted living is described as a proof-of-concept, providing both a preliminary validation of the proposed solution and a useful example of its use.

In today's world, the users of software-based products demand a lot. They want the systems to offer the needed functionality, show high performance and, at the same time, be usable and trustworthy. Especially consumer products should also offer joy to the user. The success of a software-based product strongly depends on how well the product fulfills these user expectations. Therefore, considering the users' expectations should be an integral part of modern system engineering activities. This paper shows an approach that was designed to appraise and measure the users' (future) satisfaction in an early phase of system development: the requirements engineering phase. In this phase little systematic guidance exists on how to evaluate the effects of features on user satisfaction early on, and on how to contribute the results to the development process. AMUSE (appraisal and measurement of user satisfaction), the approach presented in this paper, closes this gap. It helps requirements engineers and product managers to select the most promising features, i.e., the ones that will satisfy the user the most, already in the requirements phase. The approach uses a standardized user satisfaction measurement device (questionnaire), a feature appraisal and prioritization methodology, and tool support. This approach was developed and piloted in cooperation with Siemens AG, Germany.

Non-functional characteristics of products can be essential for business success and are a key differentiator between a company and its competitors. This paper presents the application of a systematic, experience-based method to elicit, document, and analyze non-functional requirements. The objective of the method is to achieve a minimal and sufficient set of measurable and traceable non-functional requirements. The method gives clear guidance for the requirements elicitation, using workshops for capturing the important quality aspects and eliciting the non-functional requirements. This paper shows its application in three different settings, reporting the experience and lessons learned from industrial case studies that applied our NFR method. As the case studies were applied in different domains and performed with companies of various maturity, and since different quality attributes were considered, a set of interesting results has emerged. Therefore, each case study tells its own story about how the elicitation of NFR in industry can work. The paper discusses the different settings and gives a comparison of the different lessons we learned from the case studies.