Creativity focuses on the generation of novel and useful ideas. In this paper, we propose an approach to automatically generating creative requirements candidates via the adversarial examples resulted from applying small changes (perturbations) to the original requirements descriptions. We present an architecture where the perturbator and the classifier positively influence each other. Meanwhile, we ensure that each adversarial example is uniquely traceable to an existing feature of the software, instrumenting explainability. Our experimental evaluation of six datasets shows that around 20% adversarial shift rate is achievable. In addition, a human subject study demonstrates our results are more clear, novel, and useful than the requirements candidates outputted from a state-of-the-art machine learning method. To connect the creative requirements closer with software development, we collaborate with a software development team and show how our results can support behavior-driven development for a web app built by the team.

Traceability plays an essential role in assuring that software and systems are safe to use. Automated requirements traceability faces the low precision challenge due to a large number of false positives being returned and mingled with the true links. To overcome this challenge, we present a mutation-driven method built on the novel idea of proactively creating many seemingly correct tracing targets (i.e., mutants of a state machine diagram), and then exploiting model checking within process mining to automatically verify whether the safety requirement's properties hold in the mutants. A mutant is killed if its model checking fails; otherwise, it is survived. We leverage the underlying killed-survived distinction, and develop a correlation analysis procedure to identify the traceability links. Experimental evaluation results on two automotive systems with 27 safety requirements show considerable precision improvements compared with the state-of-the-art.

Complementarity between activities reveals that doing any one of them increases the returns to doing the others. In other words, complementarity leads to the synergistic effect that the whole is greater than the sum of its parts. Identifying and exploiting complementarity can benefit many cybernetic activities, where human-machine interactions are inherent and dominant. One such activity is requirements tracing that helps stakeholders to track the status of their goals. Although various kinds of support for human analysts in requirements tracing have been proposed, little is known about the nature of complementarity when different tracing practices are involved. In this paper, we explore the role of complementarity by considering together the tagging-to-trace (T2T) and learning-to-trace (L2T) activities. We present a novel approach to examining which T2T and L2T practices enhance the qualities of each other. Our approach also uncovers the environmental factors which the complementarity is sensitive to. Applying our approach to the logs of 140 analyst-tracing units offers operational insights into the rigorous detection of complementarity and shows the importance of understanding the cybernetic conditions under which the requirements tracing practices may in fact be complementary.

In[1], Li Da Xu’s main affiliation should be Old Dominion University, Norfolk, VA 23529 USA.

To understand requirements traceability in practice, we contribute, in this paper, an automated approach to identifying questions from requirements repositories and examining their answering status. Applying our approach to 345 open-source projects results in 20622 questions, among which 53% and 15% are classified as successfully and unsuccessfully answered, respectively. By constructing a novel requirements socio-technical graph, we explore the impact of stakeholder-artifact relationships on traceability. The number of people, surprisingly, has little influence compared to other graph-theoretic measures like the clustering coefficient. Based on the repository mining results, we formulate a set of novel hypotheses about traceability. A case study supports some hypotheses while offering new insights.

Compared to building a single requirements view, modeling stakeholder viewpoints and then merging them is shown to improve the understanding of the problem domain, but also very time consuming. How has the situation changed? This paper reports our replication of a case study, where we take theoretical replication's advantage to mitigate the original study design's threat and to embrace an important evolving factor, namely automated tool support for producing i* models. Our replicate case study verifies the rich domain understanding gained through viewpoint-based modeling, and updates the prior results by showing the time saving enabled by the tool. Our work offers operational insights into independent, theoretical replications. These insights, we believe, can advance requirements engineering research toward an empirically backed body of knowledge.

For many organisations, choosing a reusable software strategy such as whether to be developing products, platforms or components, or some combination of these is not straightforward. The appropriateness of the choice can also change as an organisation's internal and external business environment context changes. In this paper we provide a management tool to help guide that decision making. We set out four broad types of business strategy and map these against four different types of reusable software development strategy. The four types of business strategy correspond to different business environments which are in turn characterised by different combinations of market predictability (low to high) and an organisation's ability to influence it (low to high). To demonstrate the framework as an analytical tool we have mapped examples of different organisations reusable software strategies and explained some circumstances in which that organisation's strategy may change.

Within software product lines, customers may have different quality needs. To produce products with purposefully different quality attributes, several challenges must be addressed. First, one must be able to distinguish product quality attributes to the customers in a meaningful way. Second, one must create the desired quality attribute differences during product-line architecture design and derivation. To study how performance is varied purposefully in software product lines, we conducted a comparison and re-analysis of two industrial case studies in the telecommunication and mobile game domains. The results show that performance variants must be communicated to the customer in a way that links to customer value and her role. When performance or its adaptation are crucial for the customer, performance differences must be explicitly "designed in" with software or hardware means. Due to the emergent nature of performance, it is important to test performance and manage how other variability affects performance.

In software product lines, feature development options can be categorized as make or buy or, a variation on buy, called reuse. In transaction economic cost theory a group of features is an asset and there is an increasing correlation between an asset's relative importance to a supplier and the decision to make rather than buy. In this paper we argue that the make or buy decision should also consider an asset's relative importance to the set of customers who buy the products containing the asset and we present a decision-making feature development framework that factors in feature relative importance to supplier and customer. To evaluate our framework we compared its recommendations with actual decisions made on three different industrial product lines. Our results showed broad consistency between framework guidance and actual practice, but revealed some instances not adequately explained by the framework.

Software modernization often involves complex code transformations that convert legacy code to new architectures or platforms, while preserving the semantics of the original programs. We present the lessons learnt from an industrial software modernization project of considerable size. This includes collecting requirements for a code-to-model transformation, designing and implementing the transformation algorithm, and then validating correctness of this transformation for the code-base at hand. Our transformation is implemented in the TXL rewriting language and assumes specifically structured C++ code as input, which it translates to a declarative configuration model. The correctness criterion for the transformation is that the produced model admits the same configurations as the input code. The transformation converts C++ functions specifying around a thousand configuration parameters. We verify the correctness for each run individually, using translation validation and symbolic execution. The technique is formally specified and is applicable automatically for most of the code-base.

Requirements engineering (RE), framed as a creative problem solving process, plays a key role in innovating more useful and novel requirements and improving a software system's sustainability. Existing approaches, such as creativity workshops and feature mining from web services, facilitate creativity by exploring a search space of partial and complete possibilities of requirements. To further advance the literature, we support creativity from a combinational perspective, i.e., making unfamiliar connections between familiar possibilities of requirements. In particular, we propose a novel framework that extracts familiar ideas from the requirements and stakeholders' comments using topic modeling and applies part-of-speech tagging to obtain unfamiliar idea combinations. We apply our framework on two large open source software systems and further report a human subject evaluation. The results show that our framework complements existing approaches by generating original and relevant requirements in an automated manner.

In Software Engineering, reuse of artifacts is essential for high productivity. Different studies have shown that efficient reuse needs systematic planning and realization. Variability Management plays a key role in Software Product Line Engineering. We investigate code artifacts and variability models of a real-world Software Product Line over time in order to clarify whether code and variability model evolve congeneric. Furthermore, we suggest and test metrics that would allow detecting variability erosion in the code based on changes in the variability model.

This tutorial explores how the prudent use of a set of requirements variability management techniques can ensure the alignment of a product line business strategy and the corresponding product platform development strategy.

Danfoss Power Electronics is a centre with both extensive power electronics know-how and many competencies within frequency converters and solar inverters. Development of embedded controllers built in Danfoss products raises similar challenges found in many other companies: creation of product series with an increasing number of variants, while at the same time decreasing time-to-market and keeping development costs low. Introduction of a Software Product Line approach into product development is a challenge that Danfoss Power Electronics decided to take in order to reduce software development efforts few years ago. The approach has been successful allowing for development of a number of highly engineered products. However, the software product line is in a constant evolution. It grows over time as new functionality is added in the form of extra software artefacts and further products are configured from it. As a result, the overall complexity and maintenance of assets hinders further efficiency of the approach. This paper presents extension of the variability management that goes beyond the scope of software assets reuse previously introduced into the organization. A prototype of the technique linking multi-level variability management is further elaborated using pure::variants.

Requirements are traditionally viewed as being free of the details of an envisioned solution and specified using purely problem domain entities. Preventing premature design in the requirements permits the available design space not to be restricted too early which might inhibit innovative designs. In practice, on many industrial projects, separating the problem and solution domain entities can be difficult, and arguably there are benefits for not doing so. Many customers feel more confident describing their requirements, often as the difference between the existing products and their needs, some customers have such intimate knowledge of their products that their requirements tend to be very specific, and if the customer knows the exact solution needed thatnaturally will reduce the cost of the requirements elicitation as well as design activities. Practitioners are challenged to understand when having solution information in requirements is sensible and when it should be avoided. In this research challenge paper, we advocate that researchers should identify differentcontexts and corresponding criteria that practitioners can use to evaluate when requirements specifications may include design information. To understand the research challenge we present experiences from real projects and suggest possible factors that affect when design information may be viable in requirements specifications.

In the consumer product market space a commercial challenge is to offer personalization of products and services for individual customers at a mass production price. One solution is the development of a software product line platform comprising a set of products that have similar functions, behaviours and properties but with sufficient variability to capture customer differences. However as a product line evolves, customer requirements change and new products are added to the product line, software producers realize the platform cannot be "stretched" indefinitely. The central problem is striking a balance between development efficiency through increasing platform commonality and customer dissatisfaction with products that have unwanted features/properties. The introduction of multiple product lines may be a better alternative. In practice, achieving the balance is a compromise between satisfying customers' requirements, minimising the costs of changes to the product line platform, and a vendor's mission, capability and capacity. This tutorial will explore the broader challenges of product line evolution but focus on platform management through describing techniques for mapping changing variability between product line requirements and a product line platform architecture, and describe the contexts for deploying multiple product lines as an alternative.

In the research on software product lines, product variants typically differ by their functionality, and quality attributes are more or less similar across products. To accumulate empirical evidence, this paper presents a descriptive case study of performance variability in a software product line of mobile network base stations. The goal is to study the motivation to vary performance, and the strategy for realizing performance variability in the product line architecture. The results highlight that the evolution of customer needs motivates performance variability; performance variability can be realized either with software or hardware variability strategy, with the latter often being prevailing; and the software strategy can be kept focused by downgrading performance.

Successful software products evolve continuously to meet the changing stakeholder requirements. For software product lines, modifying variability is an additional challenge that must be carefully tackled during the evolution of the product line. This bears considerable challenges for industry as understanding on how variability realizations advance over time is not trivial. Moreover, it may lead to an erosion of variability, which needs an investigation of techniques on how to identify the variability erosion in practice, especially in the source code. To address various erosion symptoms, we have investigated the evolution of a large-scale industrial product line over a period of four years. Along improvement goals, we have researched a set of appropriate metrics and measurement approaches in a goal-oriented way, applied them in this case study with tool support, and interpreted the results including identified erosion symptoms.

The software entities of an object-oriented system should be organized in such a way that "spatial relatedness entails semantic relatedness". We refer this as the tenet of "topical locality" and argue that it is fundamental for the code base to be navigable. In this paper, we propose a novel experimental framework to test this key tenet and use large-scale open-source projects to assess three relationships. In particular, we find that: (1) class name along with header comments conveys class body's topic; (2) a code line is indicative of its surroundings; and (3) a contiguous code fragment may serve as a snapshot of the entire class. Our work not only shows the foundations necessary for the success of many code navigation approaches, but also opens avenues for further tool enhancements.

Ensuring that the non-functional requirements (NFRs), of a system are satisfied is an essential task in software development. However, this task is complicated by the fact that many NFRs conflict with each other from multiple perspectives. It is essential to resolve conflicts collectively in a collaborative decision making process since stakeholders often disagree on how conflicts should be resolved. In this paper, we describe a method for dividing high-level NFR conflicts within a product line into more manageable sub-problems. Stakeholders make use of an argumentation based collaborative decision support system to determine which design alternatives provide the best trade-offs between NFRs. Finally, we present an empirical study in which the aforementioned system was used to resolve a single instance of an NFR conflict across 3 members of a product line. It shows that the system is effective in resolving conflicts in a collaborative decision process.

In addition to functions, the architecture of a software system defines numerous other properties, commonly referred to as non-functional or quality properties. In web applications, two well-known architectural styles are common. They are resource-oriented architectural style, implemented using RESTful principles, and message-passing architectural style, implemented in XMPP. These architectural styles have their different benefits, whereas in real applications properties of both are sometimes needed. In this paper we discuss how RESTful web architecture can be complemented with XMPP. As an example, we use a distributed content management system, which is built using RESTful design guidelines and complemented with message passing architectural style implemented on XMPP. Features of both architectural styles are used in a fashion where no negative feature interaction takes place. In the completed system, both architectural styles are clearly identifiable, and their non-functional properties are preserved.

Requirements engineering is an essential activity in creating embedded real-time systems. Companies that produce a number of partially similar products can reduce development time and cost, improve quality and simplify software maintenance by applying reuse practices. Requirements reuse is an essential enabler to achieve effective software reuse. This study describes two different approaches for requirements reuse at Danfoss. The first approach reuses those requirements that are envisioned to be common between two consecutive projects and allows changing and parameterization of parts of the requirements. The second approach organizes all requirements into a common model and explicitly manages variability and different requirement variants in this common model. The results show that both approaches can result in significant savings in reduced effort by reusing common requirements. The first approach was found to be effective when the domain maturity is low and the significant set of requirements were changed from project to project. The second approach allows high reuse potential and significant savings for stable domains, where most requirements tend to be small additions or minor changes of existing requirements.

Successful software products evolve continuously to meet the changing stakeholder requirements. For software product lines, an additional challenge is that variabilities, characteristics that vary among products, change as well over time. That challenge must be carefully tackled during the evolution of the product line infrastructure. This is a significant problem for many software development organizations, as practical guidelines on how to evolve core assets, and especially source code, are missing.

In the consumer product market space a commercial challenge is to offer personalization of products and services for individual customers at a mass production price. Product line evolution is a compromise between a vendor's commercial objectives, the existing product line design, the vendor's structure and culture, and customers' requirements. Within this context, this tutorial will describe the alignment of business and technical strategies and present a range of techniques for managing this alignment. After this tutorial the participant will be able to:

Many approaches to software product line engineering have been founded on the development of a single product line platform. However as customer requirements change and new products are added to the product line, software producers recognize that the platform cannot be "stretched" indefinitely and a significant problem is striking a balance between development efficiency by increasing platform commonality and customer dissatisfaction from products with additional undesirable features and properties.

Currently users own and use many network-connected devices such as laptop, smart phone, or tablet. The user creates content using the default applications in these devices. One approach is to share and ubiquitously access the contents through a social media. Nevertheless, the contents residing in these devices should be available from anywhere, without any explicit user activity, even the contents residing in a remote location should also appear to be locally available in the operating device. With this approach we believe a user's content gets cloudified, while still remaining operable with the existing applications. In this paper we propose to cloudify a user's content in all her mobile devices. We present a middleware that allows a user to uniformly use the existing applications on local as well as remote content, and to also share the contents in a controlled way. The middleware hides all network activity to the user, it also makes the applications almost unaware while operating on a content residing in a remote location. To evaluate our approach in a mobile device context, we also present the efficiency measures of the middleware in terms of latency in content-retrieval, as well as in terms of resource usage viz. power consumption.

The research and practice on designing and analyzing software architectures has evolved considerably during the past decade. In particular, more precise architecture modeling methods have reached industrial practice. Despite this, simple dependency diagrams are still widely used ease communication with non-technical stakeholders, to reduce need for domain knowledge, and to make initial design before detailed architecture phase. Based on our experience, seasoned architects can easily find potential architectural problems in these descriptions. In this paper, we describe a representative set of potentially problematic structures in dependency diagrams to raise relevant questions on the decisions made to create the software architecture.

Modern software product line development uses viewpoints to capture the needs of various stakeholders without resorting to a single complex model. Comparing and integrating different viewpoints help to gain insights into the product line and to derive products. Recent research has proposed conflict resolution rules for handling variability in the integration process. However, one benefit viewpoints bring is to tolerate inconsistency until the rationales about variability are better understood. In this paper, we propose a method for modeling variability when product line viewpoints are consolidated. Our method takes advantage of a lattice ordering to support late binding of variability and stakeholder traceability. We apply our method to viewpoints derived from the mobile phone domain, and show how delayed commitment can support product line evolution and product derivation.

Many organizations have started to use agile development processes to speed up the development cycle and to improve the ability of the company in reacting to changing requirements. Adopting agile practices may happen as a revolution where all old practices are removed or as a more gradual process. In this paper, we discuss lessons learnt in two agile transition processes. Based on our experience, agile processes can be used in embedded software development for products. The challenges include the varying size of user requirements, the role of system requirements, and architecturally significant requirements. It is difficult for large organizations to be agile. Work allocation for a large number of different teams with different competencies tends to decrease speed, and increase the role of design and management. We conclude that agile development in this context needs very skilled developers and has to be a combination of new and old practices.

Marketing experts emphasize that the creation of superior customer value is a key element for companies' success. Understanding how to create value for customers, however, is not trivial in practice. The purpose of this paper is to analyze the role of requirements engineering (RE) in customer value creation. The paper describes experiences gained from six Finnish companies that develop software-intensive products and services for global markets. In practice, the focus of RE activities is mainly on product features. Customer value creation is, however, more than developing a competitive set of product features. It is important for companies to understand customers' processes and develop solutions that support these processes. To enable practitioners to change the focus from feature development to customer value creation, we propose a set of RE practices.

Large industrial product lines may produce tens of thousands of variants each year. Each variant typically contains both reusable assets as well as product specific code created by different organizational units. To produce this vast number of variants the organizational resources must be used efficiently. For roadmapping this means an ability to schedule production of reusable assets so that all variants can be completed according to their requirements. When aiming for centralized variability management, roadmapping requires effective management of product line feature dependences and priorities. In this paper, we first introduce the problems haunting feature roadmapping in industrial product lines. Then we investigate how these problems can be solved using a novel approach for organizing product lines based on our practical experiences. Finally, we discuss our experiences and compare our approach with results by other researchers.

The importance of reliably achieving quality of service (QoS) requirements in service-oriented architectures is constantly increasing. This trend has changed the characteristics that are needed from the service architectures, hosting environments and to the methods to create new services. To enable hosting services with strict QoS requirements, abilities to model service requirements, identify the capabilities of the hosting environment, and effectively match those for the wanted service configuration are needed. Many current methods build theoretical models of service requirements and capabilities of the hosting infrastructure. Based on our experience, using these in commercial systems is hard. In this paper, we highlight the key requirements for commercial service oriented architectures with strict latency requirements. We also propose using empirical models of the service infrastructure to provide accurate and reliable service configuration that will match the service requirements.

Teaching software architecture design in an academic course so that it would equip the students with industrially useful capabilities is challenging. The real software architecture design problems are less clear than what the students are used to learning; the existing mass of assets of an industrial environment is hard to bring into a classroom; and so forth. We have designed a special course into an academic software engineering curriculum, taking into account the industrial needs in teaching the problem of understanding and solving demanding software architecture design problems. The course form is similar to an industrial architecture study assigned to a team of architects. In this paper, we discuss the industrial motivation for the course, the development of the course to its current form, and the lessons learned from running the course.

Product lines should be based on the business reality in the selected market segments. Since the success of the product line is determined by the success of the resulting products, it is essential to guarantee that the key requirements of each identified market segment are satisfied. A critical issue for any company pursuing product line development is the competitiveness of their products against products from other manufacturers. The competitiveness can be realized by carefully managing the differentiating requirements during the initial analysis of the product line requirements. For industrial scale product lines, the number of initial requirements can be large, seriously hindering the analysis. In this paper, we first discuss the economic foundation of differentiating requirements. Then we show how to identify the key requirements for a product line and in which way we can reduce the set of requirements that needs to be discussed during the analysis. Finally, we demonstrate our approach with a worked example where we analyze the key requirements in terms of differentiation among the products.

Software product lines have proven to be successful for developing many critical software systems. Sharing thoroughly tested components can greatly improve the quality of individual products. The structuring of commonality and variability in the product line creates dependencies among features and components. Because of the dependencies, individual products may be bloated with features and components not required by the product specification. This increases complexity and resource consumption, affecting product quality negatively. We propose a method for analyzing product line dependencies for identifying unnecessary features. If these features are found, the method also addresses how to correct the situation. Our approach is demonstrated with a running example and our experiences in real industrial cases are discussed.

Under today's fiercely competitive conditions, companies are seeking new means to develop innovative products that satisfy customer and user needs. In order to understand how requirements engineering (RE) can support innovations, we observed RE activities in six Finnish companies. Our observations indicate that RE can play a vital role in the development of innovative products. We identified three main opportunities for innovations: 1) discovering hidden customer and user needs, 2) inventing new product features that satisfy these needs, and 3) supporting feature development with an innovative technical solution. Based on our observations, as well as on existing innovation and business-management literature, we have concluded that RE research can gain significant results by investigating how to discover and model hidden customer and user needs. We believe that this would allow RE to much better support those innovation practices that provide real competitive advantage.

Variability management has long been recognized as a key part of software product family development. This article builds on this notion by presenting a set of Web service related technologies in the context of variability management. Additionally we adapt an existing process for planning variability for use with our technologies. We expect that Web service technology, already very successful in the domain of enterprise applications, would emerge as the integration technology of choice for constructing so called product family populations, i. e. populations of products constructed from multiple, independently developed product families

Software product line development is a compromise between customer requirements, existing product line architectural constraints and commercial needs. Managing variability is the key to a successful product line development. Product line models of requirements and features can be constructed that contain variation points. New products can be driven by making requirement selections from a product line model of requirements but as the product line evolves selections are constrained by the design of the existing product line architecture and the cost of making these changes. We present a set of rules that map the selection constraint values of requirements to the selection constraint values of features which in turn map on to the selection constraint values of architectural assets. We illustrate the application of the rules using a worked example.

Architecture has been identified as a main tool for high quality system development. It encapsulates the earliest design decisions of the system under development. However, these decisions heavily constrain the overall design space; therefore it is worth emphasising the reasons behind architectural choices. Methods for architecture have been suggested by various research. Unfortunately, they fail to achieve frameworks that can reason about the strong relationship between general system goals and the decisions that are made to fulfill those requirements. In this paper, we have three major contributions: (i) we introduce a general framework for the architectural design cycle. This framework describes an iterative process that assists in transforming system-wide goals into effective architectural description that satisfies the main requirements. (ii) We show how the prioritizations among goals and environmental constraints have a major impact on the resulting architecture. In addition, we demonstrate that the ordering of design decisions greatly affects what kind of structure is created. We describe how properties of earlier design decisions constrain the available design space and the concerns emerging from the current design guide selection of the next design choices. (iii) We investigate how this framework can be adapted in a concrete design example. We conclude that using this model can improve traceability, support trade-off decisions and record design rationale.

Contemporary software engineering utilizes product lines for reducing time to market and development cost of a single product variant, for improving quality of the products, and for creating better estimations of the development process. Most product line development processes rely on performing a domain analysis to find out commonalities among proposed family members and to estimate how they will vary. On the other hand, most requirements engineering methods focus on the specification of a single system. Despite active research efforts to close this, gap there is still no effective method that allows product specifications in arbitrary levels of detail for a hierarchical product family. In particular, it is not possible to combine different specification mechanisms to produce a complete family specification. The authors approach these problems by presenting a method that allows system specifications both in the product line variant as well as the product family level. This exposes many problems in managing consistency between different methods to specify families of systems. To achieve this, our method offers derivation of consistency management support between different specification levels and among family variants.

In search for improved software quality and high productivity, software reuse has become a key research area. One of the most promising reuse approaches is product families. However, current practices in requirements engineering do not support product families. This paper describes a definition hierarchy method for requirements capturing, structuring, analysis and documentation. This method helps to identify architectural drivers of the product family and shows how different products in the family vary.