The software requirements selection process has an important role in software development because it aims in identifying an (close to) optimal subset of candidate requirements by exploiting trade-offs among these requirements to satisfy the demands of users. Usually, more than one stakeholder participates in the requirements selection process analyzing important aspects in this context, such as budget, costs, available resources, and technical aspects to find a set of requirements that meets the users’ needs. In a scenario in which different stakeholders are involved, the inclusion of their preferences, decision criteria and judgment are important factors to guarantee the selection of the best requirements according to project constraints. An interactive approach to incorporate preferences from multiple stakeholders is proposed aiming to assist users in obtaining solutions as close to their needs.

The specific purpose of this doctoral research is to improve the writing of requirements at the French Space Agency (CNES) by proposing a set of linguistic rules – referred to as a Controlled Natural Language (CNL) – that engineers should follow when writing out specifications in French. CNLs for technical writing do already exist, but if they are reviewed from a linguistic point of view, they are found unsatisfactory and too constraining, because some of the rules they impose lack relevance or are not compatible with the way engineers actually specify large-scale systems. In this research abstract, we will present a methodology based on corpus analysis aimed at improving existing rules and suggesting new ones that are inspired by existing data. We will also consider requirements extracted from specifications written at CNES to demonstrate its feasibility.

The human element is often found to be the weakest link in the information security chain. The Personal Information Security Assistant project aims to address this by improving the privacy and security awareness of end-users and by aligning the user's personal IT environment to the user's security requirements. It does this by elicitation of a user's privacy and security requirements (risk appetite) as well as a user's risk perception. The PISA then takes action by aligning the user's requirements and perceptions, thereby improving user awareness regarding privacy and security. This article outlines the research questions, methodology and current results associated with the PISA project.

With the development of trustworthy services, security requirements are of paramount importance for any service (X-as-a-Service). This work-in-progress paper motivates the need for a new approach to requirements engineering for trustworthy services, which helps organisations to systematically define a set of security requirements and describe these in a service level agreement (SLA). This proposed research aims to provide adequate assurances to users by introducing the concept of the Trustworthy Service Level Agreement (TSLA). The proposed research design involves three stages: The first is to develop an initial method of Security Assurance Requirements Engineering (STARE) by refining the nine Security Quality Requirements Engineering (SQUARE) activities. The key activities of STARE include: eliciting security requirements, classification of security requirements, and developing the novel concept of the TSLA. In the second stage, the effectiveness of STARE is evaluated using two real-world case studies: state cyber defence and lawful interception as a service. Finally, the process of implementing the STARE activities will be evaluated using selected service providers that deliver such services to defence and law enforcement agencies. Given the current state of requirements engineering for services, it is anticipated that this research will have a significant impact in terms of guaranteeing secure and trustworthy services in various domains

Requirements engineers model the system of interest from different points of view by creating numerous artifacts. Although they have to deal with a great amount of information, the display space of the devices is limited. This limitation leads to a time consuming navigation through the artifacts. Requirements engineers have to scroll through numerous pages and switch between multiple windows. However, they have to rely on their memory when there is no space left on the screen to view another piece of relevant information. In this research, we propose to develop a novel visualization technique that flexibly creates editable views of a linked set of elements or artifacts where the pieces show different levels of detail according to the user’s demand for the current task. Thus, important parts are shown in detail, while the space taken for displaying unimportant parts is minimized. Our conceptual solution is a combination of the focus context concept and a magnet-and-spring system. The focus context concept is responsible for resizing and relocating objects to make space for more relevant information. The magnet-and-spring system is responsible for distributing the distortion caused by the focus context concept throughout the workspace, such that the distorted view of the information looks more natural. Considering the artifacts of a software development project as a single hypothetical artifact enables us to manage the artifacts in the same way we deal with the objects inside an artifact. Our envisaged tool support should be embeddable in requirements applications and bring its benefits to the applications manipulating requirements artifacts.

The ambiguity of natural language is an issue which predates requirement engineering. This issue is, in the general case, obviously unsolvable, nor actually needing a solution. However, we think that in particular contexts, it is feasible and desirable to reduce the ambiguity of free text specifications. We look at how specifications are actually handled in a company to be able to propose an useful but not too disruptive method for writing better specifications. We are currently developing and investigating how to validate this method.

Welcome to the 23rd IEEE International Requirements Engineering Conference, RE’15, in the beautiful multicultural city of Ottawa, Canada.

Requirement Engineering can become complex when the number of users who submit requirements is large. In the world of online Software as a Service businesses, the number of users can be massive -- often in the millions. In the case of SurveyMonkey, the world's largest survey company, it can be in the tens of millions. In a world with increasing demands and where users have a louder voice than ever via Twitter, Facebook and LinkedIn, how does one prioritize feature requests, bug fixes and everything else requested by customers and partners? Is the roadmap in the hands of the company or the users? Is this a winnable battle? In this talk, I will tell the story of how product requirements were determined when Fluidware was first established almost eight years ago and how it evolved in the various accelerated growth stages of the company before and after acquisition by SurveyMonkey.

Traceability is an important quality of software requirements and allows to describe and follow their life throughout a development project. The importance of traceable requirements is reflected by the fact that requirements standards, safety regulations, and maturity models explicitly demand for it. In practice, traceability is created and maintained by humans, which make mistakes. In result, existing traces are potentially of dubious quality but serve as the foundation for high impact development decisions. We found in previous studies that practitioners miss clear guidance on how to systematically assess the quality of existing traces. In this paper, we review the elements involved in establishing traceability in a development project and derive a quality model that specifies per element the acceptable state (Traceability Gate) and unacceptable deviations (Traceability Problem) from this state. We describe and formally define how both, the acceptable states and the unacceptable deviations can be detected in order to enable practitioners to systematically assess their project's traceability. We evaluated the proposed model through an expert survey. The participating experts considered the quality model to be complete and attested that its quality criteria are of high relevance. We further found that the experts weight the occurrence of different traceability problems with different criticality. This information can be used to quantify the impact of traceability problems and to prioritize the assessment of traceability elements.

Requirements change and so (should) do requirements artifacts, such as use cases. However, we have little knowledge about which changes requirements engineers actually perform on use cases. We do not know what is changing, at which locations use cases change and need a deeper understanding of which changes are problematic in terms of difficult or risky. To explore these challenges from an industrial point of view, we conducted a mixed methods case study in which we analyze 15 month of changes in use cases in an industrial software project. The study provided interesting observations for both practitioners and researchers involved: First, the most frequently changing use cases had an issue in their structuring. Second, alternative flows (i.e., variations or extensions of the main flow) were especially prone to changes. Third, changes in content (semantic changes) and in presentation of the content (syntactic changes) happen similarly frequently. Last, a qualitative and quantitative analysis aiming at a deeper understanding of problematic changes identified taxonomy changes, as well as locally or temporally dispersed changes as particularly difficult and risky. In this paper, we contribute a first empirical inquiry for understanding the maintainability of use cases: The presented study provides empirical evidence that there are particular maintenance risks and suggests to continuously analyze local and temporal dispersion.

Non-functional requirements (NFRs) are high-level quality constraints that a software system should exhibit. Detecting such constraints early in the process is critical for the stability of software architectural design. However, due to their pervasive nature, and the lack of robust modeling and documentation techniques, NFRs are often overlooked during the requirements elicitation phase. Realizing such constraints at later stages of the development process often leads to architecture erosion and poor traceability. Motivated by these observations, we propose an unsupervised, computationally efficient, and scalable approach for extracting and tracing NFRs in software systems. Based on main assumptions of the cluster hypothesis and information theory, the proposed approach exploits the semantic knowledge embedded in the textual content of requirements specifications to discover, classify, and trace high-level software quality constraints imposed by the system’s functional features. Three experimental systems are used to conduct the experimental analysis in this paper. Results show that the proposed approach can discover software NFRs with an average accuracy of 73%, enabling these NFRs to be traced to their implementations with accuracy levels adequate for practical applications.

Requirements are typically specified on the assumption that the system's operating environment will behave in what is considered to be an expected and nominal manner. When gathering requirements, one concern is whether the requirements are too incomplete to account for every possible, unintended, off-nominal behavior (ONB) that the operating environment can create in the system. In this paper, we present a semi-automated approach, based on the causal component model (CCM), which can expose, within a set of requirements, whether ONBs can result in undesired system states. We demonstrate how the CCM approach exposes and helps address potential off-nominal behavior problems in a set of requirements that represents a real-world product. Our case study shows that the approach can expose susceptibility to ONBs and can supply information in correcting requirements.

Requirements engineers are faced with multiple sources of uncertainty. In particular, the extent to which the identified software requirements and environment assumptions are adequate and sufficiently complete is uncertain; the extent to which they will be satisfied in the system-to-be is uncertain; and the extent to which obstacles to their satisfaction will occur is uncertain. The resolution of such domain-level uncertainty requires estimations of the likelihood that those different types of situations may or may not occur. However, the extent to which the resulting estimates are accurate is uncertain as well. This meta-level uncertainty limits current risk-based methods for requirements engineering. The paper introduces a quantitative approach for managing it. An earlier formal framework for probabilistic goals and obstacles is extended to explicitly cope with uncertainties about estimates of likelihoods of fine-grained obstacles to goal satisfaction. Such estimates are elicited from multiple sources and combined in order to reduce their uncertainty margins. The combined estimates and their uncertainties are up-propagated through obstacle refinement trees and then through the system’s goal model. Two metrics are introduced for measuring problematic uncertainties. When applied to the probability distributions obtained by up-propagation to the top-level goals, the metrics allow critical leaf obstacles with most problematic uncertainty margins to be highlighted. The proposed approach is evaluated on excerpts from a real ambulance dispatching system.

Security requirements analysis depends on how well-trained analysts perceive security risk, understand the impact of various vulnerabilities, and mitigate threats. When systems are composed of multiple machines, configurations, and software components that interact with each other, risk perception must account for the composition of security requirements. In this paper, we report on how changes to security requirements affect analysts risk perceptions and their decisions about how to modify the requirements to reach adequate security levels. We conducted two user surveys of 174 participants wherein participants assess security levels across 64 factorial vignettes. We analyzed the survey results using multi-level modeling to test for the effect of security requirements composition on participants’ overall security adequacy ratings and on their ratings of individual requirements. We accompanied this analysis with grounded analysis of elicited requirements aimed at lowering the security risk. Our results suggest that requirements composition affects experts’ adequacy ratings on security requirements. In addition, we identified three categories of requirements modifications, called refinements, replacements and reinforcements, and we measured how these categories compare with overall perceived security risk. Finally, we discuss the future impact of our work in security requirements assessment practice.

Many software systems today can be characterized as systems of systems (SoS) comprising interrelated and heterogeneous systems developed by diverse teams over many years. Due to their scale, complexity, and heterogeneity engineers face significant challenges when determining the compliance of SoS with their requirements. Requirements monitoring approaches are a viable solution for checking system properties at runtime. However, existing approaches do not adequately consider the characteristics of SoS: different types of requirements exist at different levels and across different systems; requirements are maintained by different stakeholders; and systems are implemented using diverse technologies. This paper describes a three-dimensional requirements monitoring model (RMM) for SoS providing the following contributions: (i) our approach allows modeling the monitoring scopes of requirements with respect to the SoS architecture; (ii) it employs event models to abstract from different technologies and systems to be monitored; and (iii) it supports instantiating the RMM at runtime depending on the actual SoS configuration. To evaluate the feasibility of our approach we created a RMM for a real-world SoS from the automation software domain. We evaluated the model by instantiating it using an existing monitoring framework and a simulator running parts of this SoS. The results indicate that the model is sufficiently expressive to support monitoring SoS requirements of a directed SoS. It further facilitates diagnosis by discovering violations of requirements across different levels and systems in realistic monitoring scenarios.

A properly formed requirement is testable, a necessity for ensuring that design goals are met. While challenging in productivity applications, entertainment applications such as games compound the problem due to their subjective nature. We report here on our efforts to create testable experience requirements, the associated scope challenges and challenges with test design and result interpretation. We further report on issues experienced when performing focus group testing and provide practitioner guidance.

We investigate a method to infer the implicit test status of requirements and thus increase the number of requirements for which the test status is known. The general idea is to improve the data set for measuring the maturity of the system in the current release. The inference is based on the structuring mechanisms (hierarchy, types) which are typically used to document the (natural language) requirements specification. We present a case study in the context of the development process for Mercedes-Benz passenger cars at Daimler AG. The results of the case study indicate the usefulness of the structuring mechanisms in the requirements specification as the basis for the inference. In particular, the number of requirements for which the status is known could be increased by almost a third.

Requirements engineering is a vibrant and broad research area. It covers a range of activities with different objectives. By reviewing experiments previously included in systematic literature reviews, this paper provides an overview of the dependent variables used in experimental requirements engineering research. This paper also identifies the theoretical motivation for the use of these variables in the experiments. The results show that a wide range of different variables has been applied in experiments and operationalized through both subjective assessments (e.g., subjects’ perceived utility of a technique) and objective measurements (e.g., the number of defects found in a requirements specification). The theoretical basis for these variables and operationalizations are unclear in most cases. Directions for theoretical work to identify suitable dependent variables are provided.

Many requirements engineering approaches structure and specify requirements based on the notion of modes or system states. The set of all modes is usually considered as the mode model of a system or problem domain. However, it is neither clear how such a mode model can be elicited systematically, nor whether it is realistic to elicit a mode model for a productive system with regard to size and comprehensibility. In this paper, we introduce three elicitation approaches for mode models. We applied the three approaches in an industrial automotive context and assessed the resulting mode models with respect to size, complexity, and differences to each other. Our results show that all elicitation approaches were capable of eliciting modes, which were structured in mode models with 20 to 42 modes. From these results, we conclude that it is possible to elicit manageable mode models for an entire system in a productive context. In our case, the practitioners decided to integrate our model in their feature specification and analysis process.

In August 2013, our company started work for an industrial customer. First, we developed a prototype and conducted field studies in small-scale projects. This was successful and the basis for a larger project about development of a new user interface for healthcare equipment. A main aim for us was to use this project as starting point for establishing a strategic, long-term relationship with this customer. However, we were not successful. In November 2014, our customer chose to take over the development themselves. We were too expensive, used too many hours and were not able to provide useful estimates, they said. In this paper, we describe the project and analyze causes to our customer’s decision. We also look at possible alternatives to the actions we took in the project and discuss whether we could have done better. A root cause to our customer’s dissatisfaction is related to requirements and handling of requirements.

Requirements engineering is recognized as a creative process where stakeholders jointly discover new creative ideas for innovative and novel products that eventually are expressed as requirements. This paper evaluates four different creativity techniques, namely Hall of Fame, Constraint Removal, Brainstorming, and Idea Box, using creativity workshops with students and industry practitioners. In total, 34 creativity workshops were conducted with 90 students from two universities, and 86 industrial practitioners from six companies. The results from this study indicate that Brainstorming can generate by far the most ideas, while Hall of Fame generates most creative ideas. Idea Box generates the least number of ideas, and the least number of creative ideas. Finally, Hall of Fame was the technique that led to the most number of requirements that was included in future releases of the products.

Whiteboards and paper allow for any kind of notations and are easy to use. Requirements engineers love to use them in creative requirements elicitation and design sessions. However, the resulting diagram sketches cannot be interpreted by software modeling tools. We have developed FlexiSketch as an alternative to whiteboards in previous work. It is a mobile tool for model-based sketching of free-form diagrams that allows the definition and re-use of diagramming notations on the fly. The latest version of the tool, called FlexiSketch Team, supports collaboration with multiple tablets and an electronic whiteboard, such that several users can work simultaneously on the same model sketch. In this paper we present an exploratory study about how novice and experienced engineers sketch and define ad-hoc notations collaboratively in early requirements elicitation sessions when supported by our tool. Results show that participants incrementally build notations by defining language constructs the first time they use them. Participants considered the option to re-use defined constructs to be a big motivational factor for providing type definitions. They found our approach useful for longer sketching sessions and situations where sketches are re-used later on.

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.

The growing complexity of today's software intensive systems results in an increased size of requirements specifications, which are typically documented by means of natural language (NL). Large NL requirements specifications are prone to contain defects (e.g., contradictions), and the inherent ambiguity of NL impedes automatic techniques to support the requirements engineer. In order to cope with this problem, we conceived a requirements documentation approach implemented in the tool ReqPat. Using a controlled NL, it supports an efficient requirements documentation, an automatic requirements validation, and an automatic transition to models--while still keeping the requirements understandable for all stakeholders.

The ever-growing complexity of systems makes their protection more challenging, as a single vulnerability or exposure of any component of the system can lead to serious security breaches. This problem is exacerbated by the fact that the system development community has not kept up with advances in attack knowledge. In this demo paper, we propose a holistic attack analysis approach to identify and tackle both atomic and multistage attacks, taking into account not only software attacks but also attacks that are targeted at people and hardware. To bridge the knowledge gap between attackers and defenders, we systematically analyze and refine the malicious desires of attackers (i.e., anti-goals), and leverage a comprehensive attack pattern repository (CAPEC) to operationalize attacker goals into concrete attack actions. Based on the results of our attack anal- ysis, appropriate security controls can be selected to effectively tackle potential attacks.

One of the key challenges in the software engineering lies in requirement engineering. As an important technique for modeling and analyzing requirements, software architecture has been intensively studied in recent years. Although various modeling tools have been proposed in both academy and industry, these tools typically provide limited support for analyzing nonfunctional requirements at architecture level. To address this problem, in this tool demo, we present a tool, called Breeze, that models, analyzes, and improves software architecture, with an emphasis on its non-functional requirements. In particular, Breeze has three key modules: (1) a modeling module that facilitates the modeling for software systems, (2) an analysis module that verifies non-functional requirements (e.g. safety, reliability and correctness) at the architecture level, and (3) a reconfiguration module that allows users to repair defects or to further improve architectures.

Requirements elicitation is indispensable for delivering successful services. Nevertheless, cloud service providers mostly rely on ad-hoc approaches, as there are no dedicated elicitation methods for cloud services. To address this problem, we developed the StakeCloud approach, which helps cloud providers elicit requirements for future cloud services. StakeCloud builds and analyzes fuzzy Galois lattices based on consumers’ advanced search queries for cloud services. Our StakeCloud Tool automatically builds the lattice from the given search queries. It provides the requirements analyst with extensive clustering and analysis capabilities as well as means for comparing different newly generated classes of services. These allow identifying the threshold for achieving the largest populations of satisfied consumers with a minimum set of features implemented. Further, our tool enables eliciting real requirements from global consumers unobtrusively.

In this paper, we propose an enhancement to requirements gathering interface used in open source software (OSS) development environments. Specifically we propose embedding currently used interface with reusable requirement patterns. We propose this enhancement based on the result we obtained from an experiment on the availability of requirement patterns during requirements generation in OSS development.

Goal-Orientation provides a rich framework for reasoning about systems during the Requirements Engineering (RE) phase. While critical properties like safety or security can require formal semantics, performing quantitative reasoning on semi-formal models in a much more lightweight approach reveals to be sufficient in many projects. Most of the time, existing RE tools only target specific quantification scenarios or do not provide easy mechanisms for implementing them. In order to demonstrate the ability to provide mechanisms that are both generic and powerful, we developed an extension of the Objectiver tool in three directions: (1) internal reasoning capabilities on AND-OR goal/obstacles structures, (2) close integration with an external spreadsheet application and (3) model export for building assessment tools using model-driven engineering techniques. We also demonstrate how our approach can cope with a variety of industrial scenarios requiring some form of quantification such as risk analysis, selection of design alternatives, effort estimation, and assessment of customer satisfaction.

Creating and maintaining visual models is a time-consuming step in software engineering processes. In order to support the crea-tion of some of these models, we have developed the Goal to Ar-chitecture tool (GATO). This web tool handles the creation and edition of goal models, as well as the derivation of statecharts. The particular variation of goal modelling supported by this tool contains four views: requirements view, design view, delegation view, and behavioural view.

Abstract—AUTOSAR has changed significantly how software is developed in the automotive sector. As a central standard, AUTOSAR enables reuse of software components as well as their interoperability. For AUTOSAR compliant ECU development, car manufacturers source Electronic Control Units (ECUs) from Tier-1 suppliers, but ask those Tier-1 suppliers to install AUTOSAR compliant basic software from a certified AUTOSAR-Tier-2 supplier. In this setup (to which we refer as the AUTOSAR ecosystem), the OEM has a direct business relationship with the Tier-1, but only an indirect relationship to the AUTOSAR-Tier-2 supplier, which leads to complex flows of requirements and related information between the organizations involved. In this extended abstract, we summarize preliminary results of a qualitative investigation of Requirements Engineering challenges in the AUTOSAR ecosystem. In particular, we interviewed 7 project managers from an AUTOSAR-Tier-2 supplier, and triangulated our results with 6 additional interviews with subjects from two Tier-1 suppliers and one OEM. We found that most of the requirements towards the AUTOSAR-Tier-2 supplier can be directly mapped to standard AUTOSAR components. However, a significant amount of requirements were new requirements and specific to the OEM or even a project. The well-known requirements engineering challenges we found to surface in the AUTOSAR ecosystem were mainly connected to these non-standard requirements. Standard and non-standard requirements are usually mixed, which makes it hard to fully leverage the potential benefits of reuse within the AUTOSAR standard. We argue that the holistic ecosystem perspective allows exploration of new strategies for mitigating this challenge.

What makes products cool? Can teams deliberately design for cool? What mysterious forces need to align in order to create the profoundly innovative products? To find out, we immersed ourselves in the experiences of everyday people as they used their coolest products. And we discovered there's really nothing magical about it. It's about joy and the underlying seven Cool Concepts -- the core human motivations at the very heart of joy. The Cool Concepts create a framework for guiding design and analyzing products. The Cool Concepts also require us to change our current methods for user research and design for the next generation of users and platforms. In this talk, Karen Holtzblatt articulates these key dimensions that product teams need to consider to create the cool user experience. She shares the findings of The Cool Project and introduces the audience to the Cool Concepts, organized into The Wheel of Joy in Life and The Triangle of Design.

User stories are a widely used notation for formulating requirements in agile development projects. Despite their popularity in industry, little to no academic work is available on assessing their quality. The few existing approaches are too generic or employ highly qualitative metrics. We propose the Quality User Story Framework, consisting of 14 quality criteria that user story writers should strive to conform to. Additionally, we introduce the conceptual model of a user story, which we rely on to design the AQUSA software tool. AQUSA aids requirements engineers in turning raw user stories into higher-quality ones by exposing defects and deviations from good practice in user stories. We evaluate our work by applying the framework and a prototype implementation to three user story sets from industry.

The rise of agile software development methods has led to the abandonment of many traditional practices especially in requirements engineering (RE). Agile RE is still a relatively new research area and the growing use of agile methods in large projects is forcing companies to look for more formal practices for RE. This paper describes experiences gained from a case study of a large agile project. The goal of this case study was to explore how prototyping can solve the challenges of agile RE. Our findings indicate that while prototyping can help with some challenges of agile RE such as lack of documentation, motivation for RE work and poor quality communication, it also needs complementary practices to reach its full potential. These practices include reviewing the big picture regularly, keeping track of quality requirements, and using ATDD (Acceptance Test Driven Development). Key words: prototyping, agile requirements engineering

The automotive industry is currently going through an enormous change, transitioning from being pure hardware and mechanical companies to becoming more software focused. Currently, software development is embedded into a V-Model process that defines how software requirements are extracted from system requirements. In recent years, OEMs have come to recognize the importance and opportunities offered by software, which include better management and shorter time-to-market of distinguishing features. Strategies to better utilize software include in-house software development and new ways to collaborate with suppliers. However, in their effort to take advantage of these opportunities, engineers struggle with the formal process imposed on software development. In this paper, we investigate the impact of this struggle on the flow of requirements, including challenges and practices. We found that new ways of working with requirements had emerged that are partly not supported, partly hindered by the old tooling and processes for requirements engineering. Requirements flow both vertical and horizontal in the organization and across the supply-chain. Support for the new way of working should allow us to refine requirements iteratively throughout their life-cycle, handle the discussion of rationales, and to manage assumptions. We found strategies of achieving this to differ not only between OEMs, but also between different divisions inside the OEMs.

This paper describes ongoing work to characterize the inherent ease with which a textual artifact pair can be traced using an automated technique. Software traceability approaches collect varied measures to build models that automatically recover links between pairs of natural language documents. Thus far, most of the approaches use a single-step model, such as logistic regression, to identify new traceability links; however, true traceability links are by far in the minority of what is retrieved for a typical artifact pair and this reduces the performance of such models. Instead, this paper formulates the problem of traceability links as the problem of finding, for a given logistic regression model (first step), the subsets of links in the training set giving the best accuracy (in terms of G-metric) on the test set (second step). Using hill climbing with random restart for subset selection, we found that for the ChangeStyle dataset, we can classify links with a precision up to about 83% and a recall up to about 42% using a training set as small as nine true candidate links (27%) and 136 false links (out of 503 wrong links). In order to get better performance and learn the best possible logistic regression classifier, we must “discard” elements in the trace dataset that increase noise and avoid learning on links that are not representative. This is preliminary work, but has promise as it shows that few correct examples may perform better than several poor examples. Keywords: traceability, machine learning, model, logistic regression

Software Traceability is a critical element in all safety critical software systems. Trace links are created across diverse artifacts such as requirements, design, code, test cases, and hazards -- either manually or with the help of supporting tools. The links are then used to support a range of software engineering activities including impact analysis, compliance verification, and safety inspections. For traceability to effectively support these activities it is important for the meaning and rationale of each link to be clearly communicated. It is often insufficient to know that one artifact satisfies, realizes, or complies to another. Instead, it is important to know why and how it does so. Terms and phrases used to describe artifacts are connected through composition, synonymic, and generalization relationships which often can only be interpreted by domain experts. In this RE:Next! paper we propose a novel approach for utilizing domain-specific knowledge bases to generate trace link rationales. We illustrate our approach with examples of automatically generated rationales taken from the domain of Communication and Control of a Transportation system, and from a Medical Infusion pump domain.

Interviews are the most common and effective means to perform requirements elicitation and support knowledge transfer between a customer and a requirements analyst. Ambiguity in communication is often perceived as a major obstacle for knowledge transfer, which could lead to unclear and incomplete requirements documents. In this paper, we analyse the role of ambiguity in requirements elicitation interviews. To this end, we have performed a set of customer-analyst interviews to observe how ambiguity occurs during requirements elicitation. From this direct experience, we have observed that ambiguity is a multi-dimensional cognitive phenomenon with a dominant pragmatic facet, and we have defined a phenomenological framework to describe the different types of ambiguity in interviews. We have also discovered that, rather than an obstacle, the occurrence of an ambiguity is often a resource for discovering tacit knowledge. Starting from this observation, we have envisioned the further steps needed in the research to exploit these findings.

The growing complexity and dynamics of the execution environment have been major motivation for designing self-adaptive systems. Although significant work can be found in the field of formalizing or modeling the requirements of adaptive system, not enough attention has been paid towards the requirements elicitation techniques for the same. It is still an open challenge to elicit the users' requirements in the light of various contexts and introduce the required flexibility in the system's behavior at an early phase of requirements engineering. We explore the idea of using a cognitive technique, repertory grid, to acquire the knowledge of various stakeholders along multiple dimensions of problem space and design space. We aim at discovering the scope of variations in the features of the system by capturing the intentional and technical variability in the problem space and design space respectively. A stepwise methodology for finding the right set of features in the changing context has also been provided in this work. We evaluate the proposed idea by a preliminary case study using smart home system domain.

A stakeholder’s beliefs influence his or her goals. However, a stakeholder's beliefs may not be consistent with the goals of all stakeholders of a system being constructed. Such belief-goal inconsistencies could manifest themselves as conflicting goals of the system to be. We propose Arg-ACH, a novel approach for capturing inconsistencies between stakeholders' goals and beliefs, and resolving goal conflicts. Arg-ACH employs a hybrid of (1) the analysis of competing hypotheses (ACH), a structured analytic technique, for systematically eliciting stakeholders' goals and beliefs, and (2) rational argumentation for determining belief-goal inconsistencies to resolve conflicts. Arg-ACH treats conflicting goals as hypotheses that compete with each other and the winning hypothesis as a goal of the system to be. Arg-ACH systematically captures the trail of a requirements engineer's thought process in resolving conflicts. We evaluated Arg-ACH via a study in which 20 subjects applied Arg-ACH or ACH to resolve goal conflicts in a sociotechnical system concerning national security. We found that Arg-ACH is superior to ACH with respect to completeness and coverage of belief search; length of belief chaining; ease of use; explicitness of the assumptions made; and repeatability of conclusions across subjects. Not surprisingly, Arg-ACH required more time than ACH: although this is justified by improvements in quality, the gap could be reduced through better tooling.

Model-Driven Development (MDD) is no longer a novel development paradigm. It has become mature from a research perspective and recent studies show its adoption in industry. Still, some issues remain a challenge. Among them, we are interested in the treatment of non-functional requirements (NFRs) in MDD processes. Very few MDD approaches have been reported to deal with NFRs (and they do it in a limited way). However, it is clear that NFRs need to be considered somehow in the final product of the MDD process. To better understand how NFRs are integrated into the existing MDD approaches, we have initiated the NFR4MDD project, a multi-national empirical study, based on interviews with companies working on MDD projects. Our project aims at surveying the state of the practice for this topic. In this paper, we summarize our research protocol and present the current status of our study. The discussion will focus on the peculiarities of our study's context and organization involving about 20 researchers from 8 European countries.

We present a framework for reasoning with preferences in the context of Goal-Oriented Requirements Engineering (GORE). Our choice of preference language, conditional importance networks (CI-nets), is motivated by the occurrence in requirements engineering of qualitative preferences and tradeoffs involving sets of items; such preferences are expressed more naturally in CI-nets than in other representations. Building on our past experience with CI-nets, we are improving the scalability and usability of CI-nets for specifying and analyzing requirements preferences. We discuss our ongoing work and long-term plans, including efforts to develop more efficient methods to identify conflicting preferences among possible requirements, guide negotiation of resolutions to such conflicts, and improve traceability and comprehension of requirements preferences.

We apply an existing formal framework for practical reasoning with arguments and evidence to the Goal-oriented Requirements Language (GRL), which is part of the User Requirements Notation (URN). This formal framework serves as a rationalization for elements in a GRL model: using attack relations between arguments we can automatically compute the acceptability status of elements in a GRL model, based on the acceptability status of their underlying arguments and the evidence. We integrate the formal framework into the GRL metamodel and we set out a research to further develop this framework.

We introduce a theoretical characterisation of feature lifecycles in app stores, to help app developers to identify trends and to find undiscovered requirements. To illustrate and motivate app feature lifecycle analysis, we use our theory to empirically analyse the migratory and non-migratory behaviours of 4,053 non-free features from two App Stores (Samsung and BlackBerry). The results reveal that, in both stores, intransitive features (those that neither migrate nor die out) exhibit significantly different behaviours with regard to important properties, such as their price. Further correlation analysis also highlights differences between trends relating price, rating, and popularity. Our results indicate that feature lifecycle analysis can yield insights that may also help developers to understand feature behaviours and attribute relationships.

App stores like Google Play and Apple App Store have over 3 Million apps covering nearly every kind of software and service. Billions of users regularly download, use, and review these apps. Recent studies have shown that reviews written by the users represent a rich source of information for the app vendors and the developers, as they include information about bugs, ideas for new features, or documentation of released features. This paper introduces several probabilistic techniques to classify app reviews into four types: bug reports, feature requests, user experiences, and ratings. For this we use review metadata such as the star rating and the tense, as well as, text classification, natural language processing, and sentiment analysis techniques. We conducted a series of experiments to compare the accuracy of the techniques and compared them with simple string matching. We found that metadata alone results in a poor classification accuracy. When combined with natural language processing, the classification precision got between 70-95% while the recall between 80-90%. Multiple binary classifiers outperformed single multiclass classifiers. Our results impact the design of review analytics tools which help app vendors, developers, and users to deal with the large amount of reviews, filter critical reviews, and assign them to the appropriate stakeholders.

Mobile and web applications increasingly leverage service-oriented architectures in which developers integrate third-party services into end user applications. This includes identity management, mapping and navigation, cloud storage, and advertising services, among others. While service reuse reduces development time, it introduces new privacy and security risks due to data repurposing and over-collection as data is shared among multiple parties who lack transparency into third-party data practices. To address this challenge, we propose new techniques based on Description Logic (DL) for modeling multi-party data flow requirements and verifying the purpose specification and collection and use limitation principles, which are prominent privacy properties found in international standards and guidelines. We evaluate our techniques in an empirical case study that examines the data practices of the Waze mobile application and three of their service providers: Facebook Login, Amazon Web Services (a cloud storage provider), and Flurry.com (a popular mobile analytics and advertising platform). The study results include detected conflicts and violations of the principles as well as two patterns for balancing privacy and data use flexibility in requirements specifications. Analysis of automation reasoning over the DL models show that reasoning over complex compositions of multi-party systems is feasible within exponential asymptotic timeframes proportional to the policy size, the number of expressed data, and orthogonal to the number of conflicts found.

Inconsistency is a major challenge in requirements engineering, commonly perceived as a problem that needs to be eliminated on sight. However, in practice maintaining consistency at all times is an intractable problem. Accordingly, recent paradigms for inconsistency management acknowledge that it is sometimes desirable to tolerate inconsistency, e.g. to allow distributed teamwork and prevent premature commitment to design decisions. However, a successful adoption of inconsistency management paradigms in industry highly depends on the human factor: intolerant attitudes of practitioners toward inconsistency may pose significant barriers to a wider acceptance of these paradigms. Thus, a thorough analysis of cognitive factors is a key to overcoming these barriers. In this paper we report on our preliminary empirical findings highlighting existing perceptions and attitudes of practitioners toward inconsistency, and propose dimensions for their classification. Based on these results, we outline a general research program for exploring cognitive factors in inconsistency management.

Abstract- Despite the importance of Requirements Engineering (RE) for the success of software products, most of the requirements decisions such as requirements specification and prioritization are still ad hoc and depend upon the managers' preferences and the trade-offs they make. The Technical Debt (TD) metaphor looks into the trade-offs between short term and long-term goals in software development projects that may lead to increased cost in the future. This problem is mainly due to the lack of a systematic and well-defined approach to manage the high level of uncertainty in requirements decisions. In this paper, we propose to apply the real options thinking to develop a quantitative method for managing requirements decisions under uncertainty and, more specifically for managing requirements debt in software development projects. A real option is a right without an obligation to make a specific future decision depending on how uncertainty resolves. We demonstrate the application of real options in the context of requirements debt valuation by using the binomial model combined with dynamic programming. We provide an illustrative example to show how uncertainty creates option value and influences requirements decisions and finally outline a future research agenda.

Self-adaptive systems (SASs) should be able to adapt to new environmental contexts dynamically. The uncertainty that demands this runtime self-adaptive capability makes it hard to formulate, validate and manage their requirements. QuantUn is part of our longer-term vision of requirements reflection, that is, the ability of a system to dynamically observe and reason about its own requirements. QuantUn's contribution to the achievement of this vision is the development of novel techniques to explicitly quantify uncertainty to support dynamic re-assessment of requirements and therefore improve decision-making for self-adaption. This short paper discusses the research gap we want to fill, present partial results and also the plan we propose to fill the gap.

Technology and knowledge have been recognized as main sources of competitive advantage of corporations, industries and nations, particularly in the software domain. They have led to the creation of local ecosystems devoted to development and transfer activities, which ensure not only personal and institutional motivation/recognition, but also social and economic gains. An open (ended) debate panel is proposed in order to develop greater awareness and seek deeper understanding of such activities from Requirements Engineering research to industrial practice. The panel involves researchers and practitioners with the perspective of eliciting: (i) experiences in knowledge and technology development and transfer; (ii) awareness and effectiveness of models and patterns; and (iii) factors for having successful collaboration between academic/research institutions and industry. The organizers also plan to run a survey during and after the conference, summarizing their conclusions in specific postconference reports.

The proper treatment and expression of system requirements has been a topic of interest for more than twenty years. This talk proposes that they should be understood as desired properties and effects of the behaviour of the system. A discipline to support that understanding is presented, and a brief account of the principles that underpin it.

Requirements are subject to frequent changes as a way to ensure that they reflect the current best understanding of a system, and to respond to factors such as new and evolving needs. Changing one requirement in a requirements specification may warrant further changes to the specification, so that the overall correctness and consistency of the specification can be maintained. A manual analysis of how a change to one requirement impacts other requirements is time-consuming and presents a challenge for large requirements specifications. We propose an approach based on Natural Language Processing (NLP) for analyzing the impact of change in Natural Language (NL) requirements. Our focus on NL requirements is motivated by the prevalent use of these requirements, particularly in industry. Our approach automatically detects and takes into account the phrasal structure of requirements statements. We argue about the importance of capturing the conditions under which change should propagate to enable more accurate change impact analysis. We propose a quantitative measure for calculating how likely a requirements statement is to be impacted by a change under given conditions. We conduct an evaluation of our approach by applying it to 14 change scenarios from two industrial case studies.

Goal models allow efficient representation of stakeholder goals and alternative ways by which these can be satisfied. Preferences over goals in the goal model are then used to specify criteria for selecting alternatives that fit specific contexts, situations and strategies. Given such preferences, automated reasoning tools allow for efficient exploration of such alternatives. Nevertheless, to be amenable to such automated processing, goals and preferences need to be specified in a formal language, making automated processing inaccessible to the very bearers of goals and preferences, i.e., the stakeholders. We combine natural language processing techniques to allow specification of preferences through natural language statements. The natural language statement is first matched through regular expressions to distinguish between the preference component and the goal component. The former is then mapped to a preferential strength measure, while the latter is used to identify the relevant goal in the goal model through statistical semantic similarity techniques. The result constitutes a formal representation that can be used for alternatives analysis. In this way, stakeholders can access advanced goal reasoning techniques through simple natural language preference expressions, facilitating their decision making in various requirements analysis contexts. An experimental evaluation with human participants shows that the proposed system is of substantial precision and that a mapping from natural preferential verbalizations to predefined preferential strength labels is possible through sampling from crowds.

In requirements engineering literature dealing with natural language specifications, we usually find writing rules like avoid passive voice or do not use weak words. Adhering to such rules should result in understandable and unambiguous requirements. Passive voice, especially when used without an explicit actor, is considered to result in incomplete requirements. The usage of weak words is considered to result in imprecise requirements that are hardly testable. But is the inversion of the claim correct, i.e. does the violation of the writing rules result in problematic specifications? At least in our environment (the passenger car development of Mercedes-Benz) we observe that authors often use passive voice, and there are many requirements containing weak words. To answer this question, we conducted an empirical investigation whose results we report in this paper. The results of this investigation are quite surprising: The use of passive voice, even when the actor is missing, is almost never problematic, as the missing information (the actor) can in most cases easily derived from the context (i.e. surrounding requirements or the general project context). The usage of weak words may be considered problematic in approximately 12% of all occurrences. For an automatic analysis on weak words linguistic patterns can be defined to detect these problematic occurrences.

Risk analysis and requirements engineering for safety-critical systems are expensive and challenging, especially for the very high reliability required, e.g., in the automotive and railway industries. Currently, risk analysis is performed by safety engineers with little or no explicit reuse. Of course, these engineers build on their previous experience in this course, but explicit reuse of related artefacts, e.g., from a dedicated repository is not available according to our best knowledge. The key idea of our approach is reuse in risk analysis based on development and look-up of a repository built around product line requirements. We propose explicit reuse of related artefacts from previous risk analyses, such as information on failures, hazards and safety-related risks. Our assumption is that the risk analysis of a new product of the product line can utilize this information from similar existing products, if available. Therefore, we plan to build a repository of such artefacts and to facilitate its look-up in the course of doing risk analysis. Our innovative approach to extend product-line technology has the expected result of substantially less expensive development of safety-critical systems and shorter time-to-market in such domains through reuse of existing risk-analysis artefacts.

The environment, where a safety critical system (SCS) operates, is an important source from which safety requirements of the SCS can originate. By treating the system under construction as a black box, the environment is typically documented as a number of assumptions, based on which a set of environmental safety requirements will be elicited. However, it is not a trivial task in practice to capture the environmental assumptions to elicit safety requirements. The lack of certain assumptions or too strict assumptions will either result in incomplete environmental safety requirements or waste many efforts on eliciting incorrect requirements. Moreover, the variety of operating environment for an SCS will further complicate the task, since the captured assumptions are at risk of invalidity, and consequently the elicited requirements need to be revisited to ensure safety has not been compromised by the change. This short paper presents an on-going work aiming to 1) systematically organize the knowledge of system operating environment and, 2) facilitate the elicitation of environmental safety requirements. We propose an ontological approach to achieve the objectives. In particular, we utilize conceptual ontologies to organize the environment knowledge in terms of relevant environment concepts, relations among them and axioms. Environmental assumptions are captured by instantiating the environment ontology. An ontological reasoning mechanism is also provided to support elicitation of safety requirements from the captured assumptions.

A relevant activity in the requirements engineering process consists in the identification, assessment and management of potential risks, which can prevent the system-to-be from meeting stakeholder needs. However, risk analysis techniques are often time- and resource- consuming activities, which may introduce in the requirements engineering process a significant overhead. To overcome this problem, we aim at supporting risk management activity in a semi-automated way, merging the capability to exploit existing risk-related information potentially present in a given organisation, with an automated ranking of the goals with respect to the level of risk the decision-maker estimates for them. In particular, this paper proposes an approach to address the general problem of risk decision-making, which combines knowledge about risks assessment techniques and Machine Learning to enable an active intervention of human evaluators in the decision process, learning from their feedback and integrating it with the organisational knowledge. The long term objective is that of improving the capacity of an organisation to be aware and to manage risks, by introducing new techniques in the field of risk management that are able to interactively and continuously extract useful knowledge from the organisation domain and from the decision-maker expertise.

Research projects tend to evolve through multiple phases of incubation and experimentation, before maturing to levels of full industry adoption. Practice has shown that successful research solutions often take over 20 years to achieve full technology transfer. However, many projects never leave the incubation phase either because the new technique fails to perform well, or because researchers lack the knowledge, skills, or time to transition the idea to practice. A healthy research community could be expected to produce a steady stream of innovative solutions that positively impact industrial practice. To achieve these goals, we need ongoing, rigorous, and mutually beneficial conversations between academics and practitioners. Such exchanges are a desirable part of the research process, and will help the requirements engineering community to integrate technology transfer plans into the ongoing research plans. In this interactive panel, teams of researchers, representing different requirements engineering research areas, will present their research solutions to a panel of seasoned industrial practitioners. The practitioners provide insightful feedback that can help with the transition to practice. While Ready-Set-Transfer is presented as an interactive game-show, it has the serious goal of fostering collaboration and conversations between practitioners and researchers in the requirements engineering community.

Software architects are responsible for designing an architectural solution that satisfies the functional and non-functional requirements of the system to the fullest extent possible. However, the details they need to make informed architectural decisions are often missing from the requirements specification. An earlier study we conducted indicated that architects intuitively recognize architecturally significant requirements in a project, and often seek out relevant stakeholders in order to ask Probing Questions (PQs) that help them acquire the information they need. This paper presents results from a qualitative interview study aimed at identifying architecturally significant functional requirements’ categories from various business domains, exploring relevant PQs for each category, and then grouping PQs by type. Using inter-view data from 14 software architects in three countries, we identified 15 categories of architecturally significant functional requirements and 6 types of PQs. We found that the domain knowledge of the architect and her experience influence the choice of PQs significantly. A preliminary quantitative evaluation of the results against real-life software requirements specification documents indicated that software specifications in our sample largely do not contain the crucial architectural differentiators that may impact architectural choices and that PQs are a necessary mechanism to unearth them. Further, our findings provide the initial list of PQs which could be used to prompt business analysts to elicit architecturally significant functional requirements that the architects need.

Requirements reuse promises to reduce product development cost and improve product quality. Applying a standard set of requirements to multiple products configured into the same system can ensure all the products take advantage of the system’s architectural features and do not adversely interact with each other. While existing literature provides guidance for developing requirements suitable for reuse, little has been written on the practical realities an organization faces in attempting to reuse requirements. This paper addresses that gap by describing a commercial engineering company’s deployment of a requirements reuse process, the problems encountered, the results obtained, and the plans for future improvement of the process.

The improvement and success of socio-technical systems depend on the joint optimisation of both the social and the technical parts. Improving the social part of a socio-technical system is a meticulous task, as social requirements are diverse and dynamic, and they usually evolve with time and context. Information transparency (henceforth, transparency) is one of the social requirements that can affect the overall attitude of the stakeholders present within a socio-technical system, and influence their other social requirements such as privacy, trust, collaboration and non-bias. In this paper, we advocate the need to engineer transparency as a first class requirement, propose a baseline model for transparency and show how this model can be a starting point for the analysis of transparency requirements of different stakeholders. We showcase our on-going research in the modelling and analysis of transparency as a requirement, discuss some of the challenges of transparency requirements elicitation, and present our future work.

Coherence Management refers to all efforts one needs to invest, in order to ensure that information shown in, and implied by a representation of requirements makes sense as a whole, is coherent. Coherence Management is an umbrella term we use to cover, and more importantly, stimulate research on relationships between identification, measurement, and action on phenomena which reflect tensions between information in requirements representations. Such tensions exist between information which is, for example, logically inconsistent, or stakeholders disagree on, or signals tradeoffs (meaning that improvement on some requirements, for instance, necessarily means some quantifiable (or not) deterioration of others). These tensions are an important topic of research in Requirements Engineering, and various methods have been proposed for the identification, measurement, and action on logical inconsistency in requirements models, on negotiating disagreements, and on settling tradeoffs. Despite focusing on related phenomena, these methods are different and each come with their own specific definition of when a representation of requirements is incoherent and what to do about it. This makes it hard to compare existing methods, design new ones, and choose those to apply when doing RE. In this short communication we outline our research agenda for developing a unified formal framework for the systematization and classification of Coherence Management efforts in the context of RE, as well as exploring their compatibility.

A large part of Requirements Engineering is concerned with involving system users, capturing their needs, and getting their feedback. As users are becoming more and more demanding, markets and technologies are evolving fast, and systems are getting more and more individual, a broad and systematic user involvement in Requirements Engineering is becoming more important than ever. This paper presents the idea of pushing user involvement in Requirements Engineering to its extreme by systematically delegating the responsibility for developing the requirements and deciding about future releases to the crowd of users. We summarize the pros and cons of this vision, its main challenges, and sketch promising solution concepts, which have been proposed and used in E-Participation and E-Democracy. We discussed our vision with ten experts from the fields of Requirements Engineering, politics, psychology, and market research, who were partly supportive partly skeptical.

Data-driven Natural Language Processing (NLP) methods have noticeably advanced in the past few years. These advances can be tied to the drastic growth of the quality of collaborative knowledge bases (KB) available on the World Wide Web. Such KBs contain vast amounts of up-to-date structured human knowledge and common sense data that can be exploited by NLP methods to discover otherwise-unseen semantic dimensions in text, aiding in tasks related to natural language understanding, classification, and retrieval. Motivated by these observations, we describe our research agenda for exploiting online human knowledge in Requirements Engineering (RE). The underlying assumption is that requirements are a product of the human domain knowledge that is expressed mainly in natural language. In particular, our research is focused on methods that exploit the online encyclopedia Wikipedia as a textual corpus. Wikipedia provides access to a massive number of real-world concepts organized in hierarchical semantic structures. Such knowledge can be analyzed to provide automated support for several exhaustive RE activities including requirements elicitation, understanding, modeling, traceability, and reuse, across multiple application domains. This paper describes our preliminary findings in this domain, current state of research, and prospects of our future work.