Corentin Burnay

What stakeholders will or will not say: A theoretical and empirical study of topic importance in Requirements Engineering elicitation interviews

Interviewing stakeholders is a way to elicit information about requirements for a system-to-be. A difficulty when preparing such elicitation interviews is to select the topics to discuss, so as to avoid missing important information. Stakeholders may spontaneously share information on some topics, but remain silent on others, unless asked explicitly. We propose the Elicitation Topic Map (ETM) to help engineers in preparing interviews. ETM is a diagram showing topics that may be discussed during interviews, and shows how likely stakeholders discuss each of these topics spontaneously. If a topic is less likely to be discussed spontaneously, then this suggests that engineers may want to prepare questions on it, before the interview. ETM was produced through theoretical and empirical research. The theoretical part consisted of identifying topic sets based on a conceptual model of communication context, grounded in philosophy, artificial intelligence, and computer science. The empirical part involved interviews with Requirements Engineering professionals to identify the topic sets and topics in each set, surveys of business people in order to evaluate how likely they would spontaneously share information about topics, and evaluations of how likely students would share information about each topic, when asked about requirements for social network websites.

Stimulating Stakeholders' Imagination: New Creativity Triggers for Eliciting Novel Requirements

Requirements engineering is a creative process in which stakeholders and engineers work together to create ideas for new products, services and systems. Several techniques have proved to be effective for eliciting creative requirements. Yet, most of these techniques are heavy to implement and require long periods of time to be applied correctly. Few lightweight creativity techniques have been developed for use in requirements engineering. One such lightweight technique is the creativity trigger, which provides simple guidance to stakeholders and engineers to help produce creative requirements. While easy to apply, creativity triggers were derived informally from experience of practitioners and have not been validated in a systematic way. This paper reports design and preliminary validation research, that sought to provide empirical foundations for a more complete set of lightweight creativity triggers, to be used by stakeholders and engineers to quickly and simply generate new and useful requirements on products, services and systems.

An Exploratory Study of Topic Importance in Requirements Elicitation Interviews

Interviewing stakeholders is a common way to elicit information about requirements of the system-to-be and the conditions in its operating environment. One difficulty in preparing and doing interviews is how to avoid missing the information that may be important to understand the requirements and environment conditions. Some information may remain implicit throughout the interview, if the interviewed stakeholder does not consider it important, and the business analyst fails to mention it, or a topic it relates to. We propose the so-called Elicitation Topic Map (ETM), which is intended to help business analysts prepare elicitation interviews. ETM is a diagram that shows topics that can be discussed during requirements elicitation interviews, and shows how likely it is that stakeholders tend to discuss each of the topics spontaneously (as opposed to being explicitly asked questions on that topic by the business analyst). ETM was produced through a combination of theoretical and empirical research.

A framework for the operationalization of monitoring in business intelligence requirements engineering

Business intelligence (BI) is perceived as a critical activity for organizations and is increasingly discussed in requirements engineering (RE). RE can contribute to the successful implementation of BI systems by assisting the identification and analysis of such systems’ requirements and the production of the specification of the system to be. Within RE for BI systems, we focus in this paper on the following questions: (i) how the expectations of a BI system’s stakeholders can be translated into accurate BI requirements, and (ii) how do we operationalize specifically these requirements in a system specification? In response, we define elicitation axes for the documentation of BI-specific requirements, give a list of six BI entities that we argue should be accounted for to operationalize business monitoring, and provide notations for the modeling of these entities. We survey important contributions of BI to define elicitation axes, adapt existing BI notations issued from RE literature, and complement them with new BI-specific notations. Using the i* framework, we illustrate the application of our proposal using a real-world case study.

Trust in requirements elicitation: how does it build, and why does it matter to requirements engineers?

Elicitation is a process during Requirements Engineering (RE) which intends to identify requirements and information about a system and its domain. It relies heavily on communications and interactions between engineers and stakeholders. One significant variable influencing the effectiveness of such communication is Trust. While this very idea has been widely covered in many fields of research, little attention has been paid in RE to the potential influence of trust on the elicitation effort, and therefore on the overall RE success. This paper intends to fill in this gap by providing a first empirical study on the impact of trust during requirements elicitation and by proposing a first definition of trust in the engineers and trust in the stakeholders during RE.

Are Stakeholders the Only Source of Information for Requirements Engineers? Toward a Taxonomy of Elicitation Information Sources

Requirements elicitation consists in collecting and documenting information about the requirements from a system-to-be and about the environment of that system. Elicitation forms a critical step in the design of any information system, subject to many challenges like information incompleteness, variability, or ambiguity. To deal with these challenges, requirements engineers heavily rely on stakeholders, who turn out to be one of the most significant provider of information during elicitation. Sometimes, this comes at the cost of less attention being paid by engineers to other sources of information accessible in a business. In this article, we try to deal with this issue by studying the different sources of information that can be used by engineers when designing a system. We propose TELIS (a Taxonomy of Elicitation Sources), which can be used during elicitation to review more systematically the sources of information about a system-to-be. TELIS was produced through a series of empirical studies and was partially validated through a real-world case study. Our objective in this article is to increase the awareness of engineers about the other information providers within a business. Ultimately, we believe our taxonomy may help in better dealing with classical elicitation challenges and increase the chances of successful information systems design.

How Stakeholders' Commitment May Affect the Success of Requirements Elicitation.

Requirements elicitation consists in collecting information about the requirements and the environment of a systemto-be. It usually involves business analysts who are eliciting information, and stakeholders who are providing information. This paper investigates how the commitment of stakeholders to a RE project influences the results of elicitation. We suggest a way to measure the commitment of stakeholders during RE, and propose the so-called “commitment matrix”, which shows what analysts can expect from stakeholders who are more, as opposed to those who are less committed. The matrix builds on a survey of 87 stakeholders. Our results suggest that commitment somehow affects the information provided by stakeholders, and that it is therefore a relevant criterion to account for when selecting stakeholders to be involved in elicitation. Keywords—Requirements Elicitation, Commitment, Involvement

AnalyticGraph.com: Toward Next Generation Requirements Modeling and Reasoning Tools

Graphical Requirements Modeling (GRM) consists of representing requirements in diagrams: requirements (and other relevant information) are represented as nodes, and relationships between them as edges. Relationships can show, for example, that one requirement refines another, that some are in conflict with others, that they are more or less desirable, and so on. Various software tools have been proposed over the years as a support to doing GRM, some capable of performing computations over diagrams, such as searching for text strings, or determining if a requirement is satisfied (and how much). We present yet another tool, available at AnalyticGraph.com. The tool departs from much of prior work in the following ways. (i) The tool is a web application, is available on-demand, and requires no installation of specialized software. (ii) Each model made with the tool gets its own permanent and unique URL, so that models can be linked in research papers. (iii) If a model on AnalyticGraph is linked in a paper, then any reader can click on the link, open a free account, and edit and run a copy of the linked model. (iv) The tool supports the definition of various requirements modeling languages. (v) Models are stored in a graph database, and standard graph queries (such as find the shortest path between two nodes) are included by default. (vi) It is possible to combine models made with various languages, and do computations over the resulting mixed models.

Towards a Model of Topic Relevance during requirements elicitation - Preliminary results

Requirements elicitation is the activity in requirements engineering (RE) which focuses on the collection of information about requirements of the system-to-be and its environment. One important challenge is elicitation incompleteness; it occurs when information, which may have been relevant for requirements engineering, is not elicited. This may be due to various factors, such as that the requirements engineer asked no questions about it, and the stakeholders did not consider it important. To help requirements engineers reduce elicitation incompleteness, we propose the so-called Model of Elicitation Topic Relevance (METRe). METRe is a diagram that shows topics which can be discussed during requirements elicitation, and expresses the relative importance of each topic to stakeholders and engineers. The more likely it is that a stakeholder or engineer will discuss the topic spontaneously during elicitation, the more important it is for, respectively, stakeholders or engineers. METRe was made by combining our prior work on the importance of topics to stakeholders, and a new round of empirical research. The new round consisted of data collection using a survey, in which the various topics were presented to and evaluated by 50 IT-experts in Belgium. Subjects were asked to evaluate the relative importance of the topics, that is, how relevant they find these topics when eliciting information, and how pro-active they would be in collecting them.

Investigating the Impact of Stakeholders’ Commitment on Requirements Elicitation

Requirements Elicitation (RE) consists of collecting requirements for a future system. It involves engineers who are eliciting information, and stakeholders who are involved in the project to provi...