Alessia Knauss

Openness and Requirements: Opportunities and Tradeoffs in Software Ecosystems

A growing number of software systems is characterized by continuous evolution as well as by significant interdependence with other systems (e.g. services, apps). Such software ecosystems promise increased innovation power and support for consumer oriented software services at scale, and are characterized by a certain openness of their information flows. While such openness supports project and reputation management, it also brings some challenges to Requirements Engineering (RE) within the ecosystem. We report from a mixed-method study of IBM®s CLM® ecosystem that uses an open commercial development model. We analyzed data from from interviews within several ecosystem actors, participatory observation, and software repositories, to describe the flow of product requirements information through the ecosystem, how the open communication paradigm in software ecosystems provides opportunities for `just-in-time RE, as well as some of the challenges faced when traditional requirements engineering approaches are applied within such an ecosystem. More importantly, we discuss two tradeoffs brought about the openness in software ecosystems: i) allowing open, transparent communication while keeping intellectual property confidential within the ecosystem, and ii) having the ability to act globally on a long-term strategy while empowering product teams to act locally to answer end-users context specific needs in a timely manner.

ACon: A learning-based approach to deal with uncertainty in contextual requirements at runtime

Context: Runtime uncertainty such as unpredictable operational environment and failure of sensors that gather environmental data is a well-known challenge for adaptive systems. n nObjective: To execute requirements that depend on context correctly, the system needs up-to-date knowledge about the context relevant to such requirements. Techniques to cope with uncertainty in contextual requirements are currently underrepresented. In this paper we present ACon (Adaptation of Contextual requirements), a data-mining approach to deal with runtime uncertainty affecting contextual requirements. n nMethod: ACon uses feedback loops to maintain up-to-date knowledge about contextual requirements based on current context information in which contextual requirements are valid at runtime. Upon detecting that contextual requirements are affected by runtime uncertainty, ACon analyses and mines contextual data, to (re-)operationalize context and therefore update the information about contextual requirements. n nResults: We evaluate ACon in an empirical study of an activity scheduling system used by a crew of 4 rowers in a wild and unpredictable environment using a complex monitoring infrastructure. Our study focused on evaluating the data mining part of ACon and analysed the sensor data collected onboard from 46 sensors and 90,748 measurements per sensor. n nConclusion: ACon is an important step in dealing with uncertainty affecting contextual requirements at runtime while considering end-user interaction. ACon supports systems in analysing the environment to adapt contextual requirements and complements existing requirements monitoring approaches by keeping the requirements monitoring specification up-to-date. Consequently, it avoids manual analysis that is usually costly in today’s complex system environments.

On the usage of context for requirements elicitation: End-user involvement in IT ecosystems

Todays systems are faced with the need of constant evolution to remain competitive, especially when looking at IT Ecosystems and their growing number of subsystems. As a prerequisite for these to stay competitive, system providers need a clear understanding of their stakeholders needs. As systems tend to be increasingly complex nowadays, support an increasingly number of stakeholders, have a shorter release cycles to evolve and need to adapt to the environment and the users, some of the standard requirements elicitation techniques tend not to be suitable any more. Especially when adaptivity is necessary, system providers need to understand the context, in which the systems are used, but also the context of users for the adaptation. In this paper I concentrate on the largest stakeholder group, namely the end-users for requirements elicitation. Evaluation criteria include (i) support of context, (ii) scalability to large numbers of end-users, and (iii) scalability to large numbers of end-users needs and problems that lead to new requirements. My literature review suggests that this important field is currently underrepresented in Requirements Engineering research. This research proposes to develop a framework that explains the different context types and their role for requirements elicitation. The framework is then used to investigate existing requirements elicitation techniques and their potential for considering context. It is also used to show how emerging techniques can further support requirements elicitation with context.

Eliciting contextual requirements at design time: A case study

The need to consider context in order to understand requirements is established in requirements engineering. Recently, this has been discussed more intensively for sociotechnical systems, which offer a rich spectrum of different operating contexts. Contextual requirements proved valuable to model requirements together with the context they are valid in, but there is a lack of research on how to derive them from stakeholder needs. Our goal in this paper is to explore the usefulness of existing requirements elicitation techniques for the identification of contextual requirements early, i.e. at design time. In a case study we investigate end-user viewpoints, together with interviews, scenarios, prototyping, goal-based analysis, and groupwork as a means to elicit and clarify contextual requirements already at design time. In our case study a certain combination of the applied requirements elicitation techniques stood out as most beneficial for the identification of contextual requirements. In addition, we discovered valuable indicators of differences in the operative context, for example when end-users cannot agree on refinements of specific requirements. Designers and operators of adaptive systems might benefit by taking such conflicts and resulting contextual requirements into account.

Continuous Clarification and Emergent Requirements Flows in Open-Commercial Software Ecosystems

Software engineering practice has shifted from the development of products in closed environments toward more open and collaborative efforts. Software development has become significantly interdependent with other systems (e.g. services, apps) and typically takes place within large ecosystems of networked communities of stakeholder organizations. Such software ecosystems promise increased innovation power and support for consumer-oriented software services at scale and are characterized by a certain openness of their information flows. While such openness supports project and reputation management, it also brings requirements engineering-related challenges within the ecosystem, such as managing dynamic, emergent contributions from the ecosystem stakeholders, as well as collecting their input while protecting their IP. In this paper, we report from a study of requirements communication and management practices within IBM®’s Collaborative Lifecycle Management® product development ecosystem. Our research used multiple methods for data collection, including interviews within several ecosystem actors, on-site participatory observation, and analysis of online project repositories. We chart and describe the flow of product requirements information through the ecosystem, how the open communication paradigm in software ecosystems provides opportunities for “just-in-time” RE—and which relies on emergent contributions from the ecosystem stakeholders—, as well as some of the challenges faced when traditional requirements engineering approaches are applied within such an ecosystem. More importantly, we discuss two tradeoffs brought about by the openness in software ecosystems: (1) allowing open, transparent communication while keeping intellectual property confidential within the ecosystem and (2) having the ability to act globally on a long-term strategy while empowering product teams to act locally to answer end users’ context-specific needs in a timely manner. A sufficient level of openness facilitates contributions of emergent stakeholders. The ability to include important emergent contributors early in requirements elicitation appears to be a crucial asset in software ecosystems.

Software Engineering for Smart Cyber-Physical Systems: Challenges and Promising Solutions

Smart Cyber--Physical Systems (sCPS) are modern CPS systems that are engineered to seamlessly integrate a large number of computation and physical components; they need to control entities in their environment in a smart and collective way to achieve a high degree of effectiveness and efficiency. At the same time, these systems are supposed to be safe and secure, deal with environment dynamicity and uncertainty, cope with external threats, and optimize their behavior to achieve the best possible outcome. This smartness typically stems from highly cooperative behavior, self--awareness, self--adaptation, and selfoptimization. Most of the smartness is implemented in software, which makes the software one of the most complex and most critical constituents of sCPS. As the specifics of sCPS render traditional software engineering approaches not directly applicable, new and innovative approaches to software engineering of sCPS need to be sought. This paper reports on the results of the Second International Workshop on Software Engineering for Smart Cyber--Physical Systems (SEsCPS 2016), which specifically focuses on challenges and promising solutions in the area of software engineering for sCPS.

Architectural Homeostasis in Self-Adaptive Software-Intensive Cyber-Physical Systems

Self-adaptive software-intensive cyber-physical systems (sasiCPS) encounter a high level of run-time uncertainty. State-of-the-art architecture-based self-adaptation approaches assume designing against a fixed set of situations that warrant self-adaptation; as a result, failures may appear when sasiCPS operate in environment conditions they are not specifically designed for. In response, we propose to increase the homeostasis of sasiCPS, i.e., the capacity to maintain an operational state despite run-time uncertainty, by introducing run-time changes to the architecture-based self-adaptation strategies according to environment stimuli. In addition to articulating the main idea of architectural homeostasis, we describe three mechanisms that reify the idea: (i) collaborative sensing, (ii) faulty component isolation from adaptation, and (iii) enhancing mode switching. Moreover, our experimental evaluation of the three mechanisms confirms that allowing a complex system to change its self-adaptation strategies helps the system recover from runtime errors and abnormalities and keep it in an operational state.

SACRE: A tool for dealing with uncertainty in contextual requirements at runtime

Self-adaptive systems are capable of dealing with uncertainty at runtime handling complex issues as resource variability, changing user needs, and system intrusions or faults. If the requirements depend on context, runtime uncertainty will affect the execution of these contextual requirements. This work presents SACRE, a proof-of-concept implementation of an existing approach, ACon, developed by researchers of the Univ. of Victoria (Canada) in collaboration with the UPC (Spain). ACon uses a feedback loop to detect contextual requirements affected by uncertainty and data mining techniques to determine the best operationalization of contexts on top of sensed data. The implementation is placed in the domain of smart vehicles and the contextual requirements provide functionality for drowsy drivers.

A case study of applying data mining to sensor data for contextual requirements analysis

Determining the context situations specific to contextual requirements is challenging, particularly for environments that are largely unobservable by system designers (e.g., dangerous system contexts of use and mobile applications). In this paper, we describe the application of data mining techniques in a case study of identifying contextual requirements for a context-aware mobile application to be used by a team of four long-distance rowers. The context of use for this application was dangerous and isolated, making it unobservable by the developers. The context situations for five mobile application requirements were defined by using a data mining algorithm applied to historical sensor data passively collected by the users while they crossed the Atlantic Ocean in a rowboat. The performance of the resulting classifiers is analyzed over time with promising results demonstrating that the data mining approach is feasible with implications for requirements engineering, context-aware mobile applications, and group-context-aware mobile applications.

Software-related challenges of testing automated vehicles

Automated vehicles are not supposed to fail at any time or in any situations during driving. Thus, vehicle manufactures and proving ground operators are challenged to complement existing test procedures with means to systematically evaluate automated driving. In this paper, we explore software related challenges from testing the safety of automated vehicles. We report on findings from conducting focus groups and interviews including 26 participants (e.g., vehicle manufacturers, suppliers, and researchers) from five countries.